Bug#1005906: Strace / Docker build output
--- Dockerfile --- FROM rocker/r-base:4.1.2 RUN echo "cachebust" COPY ./test_executable.sh /usr/local/bin RUN test_executable.sh RUN apt-get update && apt-get install -y strace nano RUN test_executable.sh --- Dockerfile --- --- test_executable.sh --- #!/bin/sh if test -x /usr/bin/head; then echo "/usr/bin/head is executable"; else echo "dead beef"; fi --- end test_executable.sh --- --- output from `docker build` --- Sending build context to Docker daemon 3.072kB Step 1/6 : FROM rocker/r-base:4.1.2 ---> 91af7f4c94cd Step 2/6 : RUN echo "cachebust" ---> Running in a03d2ef2988f cachebust Removing intermediate container a03d2ef2988f ---> a940509c1f09 Step 3/6 : COPY ./test_executable.sh /usr/local/bin ---> 40e0033678f6 Step 4/6 : RUN test_executable.sh ---> Running in 443f48de4a9a /usr/bin/head is executable Removing intermediate container 443f48de4a9a ---> 7c788c3ecd0e Step 5/6 : RUN apt-get update && apt-get install -y strace nano ---> Running in 20409d48b35c Ign:1 https://eddelbuettel.github.io/ppaR400 ./ InRelease Get:2 https://eddelbuettel.github.io/ppaR400 ./ Release [1,204 B] Ign:3 https://eddelbuettel.github.io/ppaR400 ./ Release.gpg Get:4 http://deb.debian.org/debian testing InRelease [129 kB] Get:5 http://deb.debian.org/debian experimental InRelease [75.4 kB] Get:6 https://eddelbuettel.github.io/ppaR400 ./ Packages [26.4 kB] Get:8 http://deb.debian.org/debian testing/main amd64 Packages [8,310 kB] Get:7 http://cdn-fastly.deb.debian.org/debian sid InRelease [165 kB] Get:9 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages [8,979 kB] Get:10 http://deb.debian.org/debian experimental/main amd64 Packages [385 kB] Fetched 18.1 MB in 8s (2,307 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libunwind8 locales Suggested packages: glibc-doc libnss-nis libnss-nisplus manpages-dev hunspell Recommended packages: manpages manpages-dev libc-devtools The following NEW packages will be installed: libunwind8 nano strace The following packages will be upgraded: libc-bin libc-dev-bin libc-l10n libc6 libc6-dev locales 6 upgraded, 3 newly installed, 0 to remove and 169 not upgraded. Need to get 13.0 MB of archives. After this operation, 7,139 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian testing/main amd64 libc-l10n all 2.33-5 [864 kB] Get:2 http://deb.debian.org/debian testing/main amd64 libc-dev-bin amd64 2.33-5 [243 kB] Get:3 http://deb.debian.org/debian testing/main amd64 libc6-dev amd64 2.33-5 [2,274 kB] Get:4 http://deb.debian.org/debian testing/main amd64 locales all 2.33-5 [4,088 kB] Get:5 http://deb.debian.org/debian testing/main amd64 libc6 amd64 2.33-5 [2,831 kB] Get:6 http://deb.debian.org/debian testing/main amd64 libc-bin amd64 2.33-5 [834 kB] Get:7 http://deb.debian.org/debian testing/main amd64 nano amd64 6.1-1 [707 kB] Get:8 http://deb.debian.org/debian testing/main amd64 libunwind8 amd64 1.3.2-2 [54.5 kB] Get:9 http://deb.debian.org/debian testing/main amd64 strace amd64 5.10-1 [1,084 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 13.0 MB in 4s (2,988 kB/s) (Reading database ... 18127 files and directories currently installed.) Preparing to unpack .../libc-l10n_2.33-5_all.deb ... Unpacking libc-l10n (2.33-5) over (2.32-4) ... Preparing to unpack .../libc-dev-bin_2.33-5_amd64.deb ... Unpacking libc-dev-bin (2.33-5) over (2.32-4) ... Preparing to unpack .../libc6-dev_2.33-5_amd64.deb ... Unpacking libc6-dev:amd64 (2.33-5) over (2.32-4) ... Preparing to unpack .../locales_2.33-5_all.deb ... Unpacking locales (2.33-5) over (2.32-4) ... Preparing to unpack .../libc6_2.33-5_amd64.deb ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline Checking for services that may need to be restarted... Checking init scripts... Unpacking libc6:amd64 (2.33-5) over (2.32-4) ... Setting up libc6:amd64 (2.33-5) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline (Reading database ... 18133 files and directories currently installed.) Preparing to unpack .../libc-bin_2.33-5_amd64.deb ... Unpacking libc-bin (2.33-5) over (2.32-4) ... Setting up libc-bin (2.33-5) ... Selecting previously unselected package nano. (Reading database ... 18133 files and directories currently installed.) Preparing to unpack .../archives/nano_6.1-1_amd64.deb ... Unpacking nano (6.1-1) ... Selecting previously unselected package libunwind8:amd64. Preparing to unpack .../libunwind8_1.3.2-2_amd64.deb ... Unpacking libunwind8:amd64 (1.3.2-2) ... Selecting previously unselected package strace. Preparing to unpack .../strace_5.10-1_amd64.deb ... Unpacking
Bug#1005906: CIFS options
Possibly important information: the docker container is running on a networked file system. //fileShares.X.X.X/Bioinformatics on /var/autofs/Bioinformatics type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict, username=XXX,domain=XXX,uid=0,noforceuid,gid=0, noforcegid,addr=10.0.0.XXX,file_mode=0777, dir_mode=0777,nounix,serverino,mapposix, rsize=1048576,wsize=1048576,echo_interval=60, actimeo=1)
Bug#1005906: libc6: 'test -x' ignores executable bit on files and directories
Package: libc6
Version: 2.33-6
Severity: important
X-Debbugs-Cc: b...@gringene.org
Dear Maintainer,
I'm not sure which package this bug is linked to; I'm fairly confident it's one
of the following:
fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev
I was trying to get R working on a Docker container with the following
Dockerfile:
--- BEGIN ---
FROM rocker/r-base:4.1.2
## This works
RUN R -e 'install.packages(c("rjson"))'
RUN apt-get update && apt-get install -y \
libfontconfig1-dev
## This doesn't work
RUN R -e 'install.packages(c("rjson"))'
--- END ---
Unfortunately, the R command stops working after the packages are updated. At
the time I ran this,
the following packages were pulled in:
fontconfig-config libbrotli-dev libbrotli1 libc-bin libc-dev-bin libc-l10n
libc6 libc6-dev libexpat1 libexpat1-dev libfontconfig-dev libfontconfig1
libfreetype-dev libfreetype6 libfreetype6-dev libuuid1 locales uuid-dev
I get similar results [i.e. R not working] when I try to install 'nano' instead
of libfontconfig1-dev.
I opened up the docker container to try to work out what was happening, and
noticed the R command
has the following logic:
if test -x "${R_HOME}"; then
:
else
error "R_HOME ('${R_HOME}') not found"
fi
When I changed this to a 'test -d', R started working again:
if test -d "${R_HOME}"; then
:
else
error "R_HOME ('${R_HOME}') not found"
fi
Unfortunately, this didn't fix all my problems, because there was another R
INSTALL script that
was required for installing R packages, and this script also didn't work. The
script had a simiar
'-x' command, but it was used to test to make sure a file was executable,
instead of a directory.
I created a short test shell commands to demonstrate the issue:
# export R_HOME=/usr/lib/R
# ls -lh ${R_HOME}/bin/INSTALL
-rwxr-xr-x 1 root root 825 Nov 1 11:00 /usr/lib/R/bin/INSTALL
# if test -x "${R_HOME}/bin/INSTALL"; then echo "file is executable"; else echo
"dead beef"; fi
dead beef
[note that this reports "dead beef", rather than stating that the file is
executable, even though
'ls' reports the file as executable]
As I believed this to have an effect beyond R, I am reporting this under one of
the packages
that was installed by apt. This package is likely incorrect; please reassign as
necessary.
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.4.0-194-generic (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libc6 depends on:
ii libgcc-s1 11.2.0-16
Versions of packages libc6 recommends:
ii libidn2-0 2.3.0-5
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.77
pn glibc-doc
ii libc-l10n 2.33-5
pn libnss-nis
pn libnss-nisplus
ii locales2.33-5
-- debconf information:
libraries/restart-without-asking: false
glibc/kernel-not-supported:
glibc/upgrade: true
glibc/kernel-too-old:
glibc/restart-failed:
glibc/disable-screensaver:
glibc/restart-services:
Bug#1001048: vfychain: segmentation fault when trying to verify signatures signed with large keys
My mistake, sorry. I've noticed after looking at the package versions that libnss3 is v2:3.68-1, which is not the same as the libnss3-tools version [i.e. 3.73-1].
Bug#1001048: vfychain: segmentation fault when trying to verify signatures signed with large keys
Package: libnss3-tools Version: 2:3.73-1 Severity: important X-Debbugs-Cc: bugrepo...@gringene.org Dear Maintainer, I've recently noticed a bug in nss that was reported on Google Project Zero: https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html The reporter's claim is as follows: > The maximum size signature that this structure can handle is whatever the > largest union member is, in this case that’s RSA at 2048 bytes. That’s 16384 > bits, large enough to accommodate signatures from even the most ridiculously > oversized keys. > Okay, but what happens if you justmake a signature that’s bigger than > that? > Well, it turns out the answer is memory corruption. Yes, really. I have tried out their example code on my Debian system, and it results in the reported Segmentation fault. This is interesting, given that the stated fixed version is NSS 3.73.0, and Debian is reporting that 3.73-1 is installed. -- System Information: Debian Release: 11.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnss3-tools depends on: ii libc6 2.31-13+deb11u2 ii libnspr4 2:4.32-1 ii libnss3 2:3.68-1 ii zlib1g1:1.2.11.dfsg-2 libnss3-tools recommends no packages. libnss3-tools suggests no packages. -- no debconf information
Bug#793170: pulseaudio: Audio system hangs (120s timeout) while waiting for pulseaudio connection
On 23/07/15 00:21, Felipe Sateler wrote: This looks like a kernel issue. Please try newer and older kernels, to see if the problem is fixed. This seems to be working now on my current system. Weird. Linux elegans 4.1.0-trunk-amd64 #1 SMP Debian 4.1.2-1~exp1 (2015-07-11) x86_64 GNU/Linux -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793170: pulseaudio: Audio system hangs (120s timeout) while waiting for pulseaudio connection
Removing the Logitech USB headset appears to have fixed the hanging problem, which is a suitable temporary fix. A combination of earbuds and webcam microphone will probably do in the future while this bug is dealt with. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793170: pulseaudio: Audio system hangs (120s timeout) while waiting for pulseaudio connection
Package: pulseaudio Version: 6.0-2 Severity: normal Dear Maintainer, After a system upgrade ~2 weeks ago, my audio system started to hang, and I can no longer play any audio files or videos. I'm also unable to reboot or shutdown, because the system hangs indefinitely waiting for the pulseaudio process to terminate (although SysRq+B still works). Things I have tried (without success): * Restarting/killing pulseaudio server (can't be killed) * Changing kernels * Removing alsa * Changing to system-wide pulseaudio * Adding 'tsched=0' to udev/hal-detect lines in default.pa/system.pa * Switching window managers (KDE - new KDE / plasma, MATE) I would like to be able to play audio, as it is useful for video conferencing on this computer. Here are some kernel lines that may be useful (notice the 120s gap between successive messages): [ /var/log/messages ] Jul 21 17:18:28 elegans pulseaudio[3077]: [autospawn] lock-autospawn.c: Cannot access autospawn lock. Jul 21 17:23:31 elegans kernel: [ 312.771428] snd_hda_intel :02:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x305f3100 Jul 21 17:23:33 elegans pulseaudio[5913]: [pulseaudio] source.c: Default and alternate sample rates are the same. Jul 21 17:23:43 elegans kernel: [ 324.863398] xhci_hcd :0a:00.0: xHCI host not responding to stop endpoint command. Jul 21 17:23:43 elegans kernel: [ 324.863406] xhci_hcd :0a:00.0: Assuming host is dying, halting host. Jul 21 17:23:43 elegans kernel: [ 324.863558] usb 3-1: USB disconnect, device number 2 Jul 21 17:26:18 elegans kernel: [ 480.346841] kworker/2:2 D 0 150 2 0x Jul 21 17:26:18 elegans kernel: [ 480.346885] Workqueue: usb_hub_wq hub_event [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.346888] 880ff3335430 0246 880ff8a72250 0006 Jul 21 17:26:18 elegans kernel: [ 480.346893] 880ff2a1ffd8 880ff3066304 880ff3335430 Jul 21 17:26:18 elegans kernel: [ 480.346897] 880ff3066308 880ff32ac000 8156483f 880ff3066300 Jul 21 17:26:18 elegans kernel: [ 480.346902] Call Trace: Jul 21 17:26:18 elegans kernel: [ 480.346912] [8156483f] ? schedule+0x2f/0x80 Jul 21 17:26:18 elegans kernel: [ 480.346916] [81564b5e] ? schedule_preempt_disabled+0xe/0x20 Jul 21 17:26:18 elegans kernel: [ 480.346921] [81566935] ? __mutex_lock_slowpath+0x95/0x110 Jul 21 17:26:18 elegans kernel: [ 480.346930] [815669cb] ? mutex_lock+0x1b/0x30 Jul 21 17:26:18 elegans kernel: [ 480.346943] [a001dfb3] ? usb_unlocked_disable_lpm+0x23/0x50 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.346957] [a002e504] ? usb_unbind_interface+0x54/0x2a0 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.346967] [813eff3e] ? __device_release_driver+0x7e/0x100 Jul 21 17:26:18 elegans kernel: [ 480.346972] [813ee9e0] ? bus_uevent_store+0x50/0x50 Jul 21 17:26:18 elegans kernel: [ 480.346976] [813effe2] ? device_release_driver+0x22/0x30 Jul 21 17:26:18 elegans kernel: [ 480.346980] [813ef8a3] ? bus_remove_device+0x103/0x180 Jul 21 17:26:18 elegans kernel: [ 480.346985] [813ebe6e] ? device_del+0x12e/0x260 Jul 21 17:26:18 elegans kernel: [ 480.346999] [a002bcd1] ? usb_disable_device+0x91/0x290 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.347012] [a0020fcd] ? usb_disconnect+0x8d/0x2d0 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.347020] [8101d196] ? native_sched_clock+0x26/0x90 Jul 21 17:26:18 elegans kernel: [ 480.347033] [a0021269] ? hub_quiesce+0x59/0xc0 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.347045] [a0022d65] ? hub_event+0x155/0x16e0 [usbcore] Jul 21 17:26:18 elegans kernel: [ 480.347051] [8109d737] ? update_curr+0xd7/0x120 Jul 21 17:26:18 elegans kernel: [ 480.347056] [810a44bd] ? pick_next_task_fair+0x1ad/0x850 Jul 21 17:26:18 elegans kernel: [ 480.347061] [810125cb] ? __switch_to+0x14b/0x5d0 Jul 21 17:26:18 elegans kernel: [ 480.347066] [81085082] ? process_one_work+0x152/0x420 Jul 21 17:26:18 elegans kernel: [ 480.347070] [81085bb3] ? worker_thread+0x53/0x540 Jul 21 17:26:18 elegans kernel: [ 480.347074] [81085b60] ? rescuer_thread+0x3a0/0x3a0 Jul 21 17:26:18 elegans kernel: [ 480.347079] [8108ab41] ? kthread+0xc1/0xe0 Jul 21 17:26:18 elegans kernel: [ 480.347084] [8108aa80] ? kthread_create_on_node+0x180/0x180 Jul 21 17:26:18 elegans kernel: [ 480.347089] [81568dd8] ? ret_from_fork+0x58/0x90 Jul 21 17:26:18 elegans kernel: [ 480.347093] [8108aa80] ? kthread_create_on_node+0x180/0x180 Jul 21 17:26:18 elegans kernel: [ 480.348302] alsa-sink-USB A D 88103fc94400 0 5987 1 0x Jul 21 17:26:18 elegans kernel: [ 480.348307] 880036cae210 880fff083c00 880ff88d4a60 03e0 Jul 21
Bug#781638: openscad: Openscad places build time into compiled output
Package: openscad Version: 2014.03+dfsg-1 Severity: minor Dear Maintainer, OpenSCAD fails reproducibility testing due to using the build date in the compiled output: https://reproducible.debian.net/rb-pkg/unstable/amd64/openscad.html A patch to remove use of the offending '__DATE__' macro is attached. -- Package-specific info: Output of /usr/share/bug/openscad: $ glxinfo |grep 'OpenGL .* string:' OpenGL vendor string: nouveau OpenGL renderer string: Gallium 0.4 on NVA8 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.2 OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 10.4.2 OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.4.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0 -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17-rc5-amd64 (SMP w/12 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openscad depends on: ii libboost-filesystem1.55.0 1.55.0+dfsg-3 ii libboost-program-options1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.01.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-3 ii libboost-thread1.55.0 1.55.0+dfsg-3 ii libc6 2.19-15 ii libcgal10 4.5-2 ii libgcc1 1:4.9.2-10 ii libgl1-mesa-glx [libgl1]10.4.2-2 ii libglew1.10 1.10.0-3 ii libglib2.0-02.42.1-1 ii libglu1-mesa [libglu1] 9.0.0-2 ii libgmp102:6.0.0+dfsg-6 ii libmpfr43.1.2-3 ii libopencsg1 1.3.2-2+b1 ii libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libstdc++6 4.9.2-10 ii libx11-62:1.6.2-3 Versions of packages openscad recommends: pn openscad-mcad none Versions of packages openscad suggests: pn geomview none ii librecad 2.0.4-1 pn meshlab none pn openscad-testing none -- no debconf information diff -u5 -r openscad-2014.03+dfsg/src/PlatformUtils.cc openscad-2014.03+notimestamp/src/PlatformUtils.cc --- openscad-2014.03+dfsg/src/PlatformUtils.cc 2014-03-11 08:01:31.0 +1300 +++ openscad-2014.03+notimestamp/src/PlatformUtils.cc 2015-04-01 16:15:45.641731816 +1300 @@ -145,11 +145,11 @@ #endif // ENABLE_CGAL const char *env_path = getenv(OPENSCADPATH); s OpenSCAD Version: TOSTRING(OPENSCAD_VERSION) - \nCompiler, build date: compiler_info , __DATE__ + \nCompiler: compiler_info \nBoost version: BOOST_LIB_VERSION \nEigen version: EIGEN_WORLD_VERSION . EIGEN_MAJOR_VERSION . EIGEN_MINOR_VERSION \nCGAL version, kernels: TOSTRING(CGAL_VERSION) , cgal_3d_kernel , cgal_2d_kernel , cgal_2d_kernelEx \nOpenCSG version: OPENCSG_VERSION_STRING \nQt version: qtVersion
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
On 15/09/14 04:16, Carsten Schoenert wrote: what about writing some lines about your problem and the solution into the Debian wiki? It isn't as hard as it seems. So than we could close this bug report ... Done, see https://wiki.debian.org/Firefox -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
Tags: fixed I ran strace on icedove and noticed that it was complaining about having trouble finding libraries associated with the google talk plugin. I uninstalled the googletalk package (Debian package made by google), and it still crashed with the same message. I then looked in my mozilla plugins directory and found some google talk plugins, presumably from an older installation of google talk. $ ls ~/.mozilla/plugins/ libnpasperaweb.so libnpgoogletalk.so libnpgtpo3dautoplugin.so libnpo1d.so Deleting these google talk plugins [rm ~/.mozilla/plugins/libnpg*] made both firefox and iceweasel work again. ... unfortunately I overwrote the bad strace with the strace from a working icedove, and no longer have the precise version of the offending plugin, so can't show the exact error that strace had produced that led me to this fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
My general advice to others who are having similar issues relating to firefox/iceweasel terminating on startup without a trace is to run strace and then look at the last few lines to see if anything looks odd: $ strace firefox http://offending_page.url 2 firefox_strace_$(date +%Y-%b-%d_%H:%M:%S).txt $ strace iceweasel 2 firefox_iceweasel_$(date +%Y-%b-%d_%H:%M:%S).txt [date/time included so that you don't make the same mistake as I did and overwrite those very useful 'fail' files with working ones] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
On Fri, Jul 11, 2014 at 02:35:50PM +1200, David Eccles (gringer) wrote: so this bug is not Icedove related, I think. I would like to reassign it to the iceweasel package, that's o.k. for you? Well, I'd expect similar results if I visited those webpages in icedove (assuming it could get that far). I'm just using the iceweasel bugs for demonstration of the consistency and inconsistency of the error because I can't get icedove to work *at all*, and the message output when the program stops is identical. Is there some metapackage that corresponds to both icedove and iceweasel that this can apply to? If so, that would be the best reassignment to do. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
Package: icedove Version: 31.0~b1-2 Severity: important Dear Maintainer, icedove crashes (or gracefully terminates) on startup, before showing any graphical elements, after showing the following message: Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)-r_state == RT_CONSISTENT' failed! It would be nice if I could actually use this program for email, rather than it just being an error message generator on the console. gdb doesn't report anything strange -- I'm not able to backtrace anything after the program terminates: [Thread 0x7fffb2afe700 (LWP 9887) exited] [Thread 0x7fffb53ff700 (LWP 9882) exited] Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)-r_state == RT_CONSISTENT' failed! [Thread 0x7fffb5d1b700 (LWP 9883) exited] [Thread 0x7fffb3cff700 (LWP 9885) exited] [Thread 0x7fffb6b8e700 (LWP 9880) exited] [Thread 0x7fffdc6f9700 (LWP 9878) exited] [Thread 0x7fffdc87c700 (LWP 9875) exited] [Thread 0x7fffdc97e700 (LWP 9873) exited] [Thread 0x7fffdc9ff700 (LWP 9872) exited] [Thread 0x7fffdcefe700 (LWP 9871) exited] [Thread 0x7fffdd88c700 (LWP 9870) exited] [Thread 0x7fffb32ff700 (LWP 9886) exited] [Thread 0x7fffdc77a700 (LWP 9877) exited] [Thread 0x7fffdb475700 (LWP 9879) exited] [Thread 0x7fffdc8fd700 (LWP 9874) exited] [Thread 0x7fffdc7fb700 (LWP 9876) exited] [Thread 0x7fffde6f0700 (LWP 9869) exited] [Thread 0x7fffdfdfe700 (LWP 9868) exited] [Thread 0x7fffe07f0700 (LWP 9867) exited] [Thread 0x7fffdd6ff700 (LWP 9866) exited] [Thread 0x76d59700 (LWP 9865) exited] [Thread 0x7fffde2ff700 (LWP 9857) exited] [Thread 0x7fffdeef1700 (LWP 9856) exited] [Thread 0x7fffdf6f2700 (LWP 9855) exited] [Thread 0x7fffe05ff700 (LWP 9854) exited] [Thread 0x7fffe1c9a700 (LWP 9853) exited] [Thread 0x77fc3740 (LWP 9848) exited] [Inferior 1 (process 9848) exited with code 0177] (gdb) bt No stack. Downgrading to icedove version 24.5.0-2 is a suitable workaround for this issue, although that doesn't actually fix anything. This has been a problem in the past for me using iceweasel, but I've been able to work around it by downgrading iceweasel. A downgrade of iceweasel stopped working a few days ago, but the iceweasel version of this bug seems to have been fixed in the past day or so (with version 31.0~b3-1), presumably due to bug 751569 getting fixed. Various messages about this issue on the web (mostly relating to skype) suggest reinstalling 32bit and/or glib-related packages, so I have tried reinstalling the following packages with no success: * libstdc++6 libc * 'lib32 ~i' * 'glib ~i' * libgl1-mesa-glx:amd64 libgl1-mesa-glx:i386 libgl1-mesa-dri:amd64 libgl1-mesa- dri:i386 The bugzilla patch related to the fix for debian bug 751569 looks like it is a little bit more cautious when deleting symbols: https://bug1025576.bugzilla.mozilla.org/attachment.cgi?id=8440362 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedove depends on: ii debianutils 4.4 ii fontconfig2.11.0-5 ii libasound21.0.28-1 ii libatk1.0-0 2.12.0-1 ii libc6 2.19-5 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-1 ii libffi6 3.1-2 ii libfontconfig12.11.0-5 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.9.0-10 ii libgdk-pixbuf2.0-02.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.24-1 ii libhunspell-1.3-0 1.3.3-2 ii libnspr4 2:4.10.6-1 ii libnss3 2:3.16.1-1 ii libpango-1.0-01.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-0 1.36.3-1 ii libpixman-1-0 0.32.4-1 ii libsqlite3-0 3.8.5-2 ii libstartup-notification0 0.12-3 ii libstdc++64.9.0-10 ii libvpx1 1.3.0-2 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii libxrender1 1:0.9.8-1 ii libxt61:1.1.4-1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-1 Versions of packages icedove recommends: ii myspell-en-gb [myspell-dictionary] 1:3.3.0-4 ii myspell-en-us [myspell-dictionary] 1:3.3.0-4 Versions of packages icedove suggests: ii fonts-lyx 2.0.6-1 ii libgssapi-krb5-2 1.12.1+dfsg-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of
Bug#754437: icedove terminates on startup with 'Inconsistency detected' message
On 11/07/14 13:53, David Eccles (gringer) wrote: This has been a problem in the past for me using iceweasel, but I've been able to work around it by downgrading iceweasel. A downgrade of iceweasel stopped working a few days ago, but the iceweasel version of this bug seems to have been fixed in the past day or so (with version 31.0~b3-1), presumably due to bug 751569 getting fixed. Scratch that. I still get crashes using iceweasel, but they're just not happening at startup: Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)-r_state == RT_CONSISTENT' failed! This only [now] happens on iceweasel after viewing html-ish pages (apart from the start page), but the crashing is inconsistent: * http://localhost:631/ [cups server, no crash] * file:///home/gringer/ [local file listing, crashes] * file:///home/gringer/public_html [local file listing, crashes] * file:///home/gringer/inkscape/clocks/ [local file listing, no crash] * file:///home/gringer/inkscape/clocks/malaghan/malaghan_clock_v3.svg [svg image, no crash] * file:///home/gringer/malaghan_clock_v3.svg [same file copied to a different location, no crash] * elegans.local/jbrowse [JBrowse genome browser, hosted on my computer, no crash] * elegans.local/~gringer/ [file listing for my user directory, no crash] * http://www.gringene.org/concentric_clock.svg [remote svg file, hosted on a server I own, no crash] * http://www.gringene.org/pastimes.html [remote HTML file, no crash] * http://www.gringene.org [remote HTML file with embedded SVG, crash] * http://openclipart.org [remote website, starts loading then crashes -- I can stop loading, and then navigate the front page] * https://openclipart.org/people/gringer/concentric_clock.svg [remote SVG file, no crash] * https://openclipart.org/image/2400px/svg_to_png/194481/concentric_clock.png [remote PNG file, no crash] * https://openclipart.org/detail/194481/concentric-loop-clock-grey-without-background-by-gringer-194481 [remote HTML page, loads text then crashes] This behaviour is weird. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726092: Rebuild on my system seems to fix this problem
So it turns out I had a local install at /home/$user/perl5 which was messing up the running of Perl -- I noticed this after running into the same problem with another module today. - D -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726092: libboost-geometry-utils-perl: Perl API version does not match installed version of Perl
Package: libboost-geometry-utils-perl Version: 0.15-1+b1 Severity: important I've been having trouble running Repetier-Host effectively after a debian update a few days ago. The current problem is an API mismatch error when running the Slic3r program, which uses Boost::Geometry::Utils: 20:05:30.986 : Slic3r command:/home/grinja/install/reprap/repetier/RepetierHost/Slic3r/slic3r.pl --load /home/grinja/repetier/slic3r.ini --print-center 90,90 -o /home/grinja/repetier/composition.gcode /home/grinja/repetier/composition.obj 20:05:31.481 : Slic3r Perl API version v5.14.0 of Boost::Geometry::Utils does not match v5.18.0 at /usr/share/perl/5.18/XSLoader.pm line 92. 20:05:31.481 : Slic3r Compilation failed in require at /home/grinja/install/reprap/slic3r/git/Slic3r/lib/Slic3r.pm line 36. 20:05:31.481 : Slic3r BEGIN failed--compilation aborted at /home/grinja/install/reprap/slic3r/git/Slic3r/lib/Slic3r.pm line 36. 20:05:31.482 : Slic3r Compilation failed in require at /home/grinja/install/reprap/repetier/RepetierHost/Slic3r/slic3r.pl line 13. 20:05:31.482 : Slic3r BEGIN failed--compilation aborted at /home/grinja/install/reprap/repetier/RepetierHost/Slic3r/slic3r.pl line 13. So instead of slicing up my 3D model, the program died. My guess from this error is that Boost::Geometry::Utils was built for Perl v5.14.0, rather than the currently installed version (v5.18.1), and this makes Perl sad. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost-geometry-utils-perl depends on: ii libc6 2.17-93 ii libgcc1 1:4.8.1-10 ii libstdc++6 4.8.1-10 ii perl5.18.1-4 ii perl-base [perlapi-5.18.1] 5.18.1-4 libboost-geometry-utils-perl recommends no packages. libboost-geometry-utils-perl 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#726092: Rebuild on my system seems to fix this problem
A simple rebuild fixes this problem (via apt-get source, then dpkg-buildpackage, then dpkg -i package.deb). Presumably the current Debian binary package was last updated prior to the Perl API change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725315: alsa-utils: Default sound card switches after changing Logitech USB headset
Package: alsa-utils Version: 1.0.27.1-1 Severity: normal I've noticed that the audio for my Logitech USB headset will stop after any volume change. However, I expect the audio to continue playing in my headset at a different volume. This muting persists until the program plays another file, or another program is started up. The problem seems to also happen when the volume is changed automatically (e.g. from the google chat plugin). I have since discovered that this is because the audio switches to another sound device at this time (i.e. the headset mutes, and the intel audio controller picks up the sound). * The problem exists in a browser if I change the volume using the volume control knob on my keyboard. * It also happens when I use mplayer within konsole, playing two different sounds at once [both sounds switch to the other sound card] * It also happens on the console -- I can switch to tty1 to play sound, switch to tty2 to change volume, and the sound mutes However... * Changing volume using the VLC volume control does not cause this issue I'm not sure if this is the correct package, but I'm hoping that the alsa folks will have a better idea where the issue lies. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages alsa-utils depends on: ii kmod9-3 ii libasound2 1.0.27.2-1 ii libc6 2.17-93 ii libncursesw55.9+20130608-1 ii libsamplerate0 0.1.8-5 ii libtinfo5 5.9+20130608-1 ii lsb-base4.1+Debian12 ii whiptail0.52.15-3 Versions of packages alsa-utils recommends: ii alsa-base 1.0.25+3 alsa-utils 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#687968: Upstream now at v2.1.1
The upstream source has been updated again to v2.1.1 (as of 2013-Apr-11), which is a minor bugfix release from v2.1.0. The 2.1.x release is a substantial improvement over previous releases according to the cufflinks page: http://cufflinks.cbcb.umd.edu/ I don't see any easily accessible source repository, but here's the source code link from that page: http://cufflinks.cbcb.umd.edu/downloads/cufflinks-2.1.1.tar.gz Previous versions are downloadable from the directory, but there is no -latest symlink: http://cufflinks.cbcb.umd.edu/downloads/ I get an error when trying to compile 2.1.1 from source on Debian at the configure stage: checking for bamlib... configure: error: We could not detect the bam libraries (version or higher). If you have a staged bam library (still not installed) please specify $BAM_ROOT in your environment and do not give a PATH to --with-bam option. If you are sure you have bam installed, then check your version number looking in bam/version.hpp. See http://randspringer.de/bam for more documentation. autoreconf suggests there is probably other modernisation work to do as well (which is beyond my current abilities unfortunately -- I'm not familiar with the autotools): configure.ac:38: the top level configure.ac:39: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2590: _AC_COMPILE_IFELSE is expanded from... ../../lib/autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from... ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... ../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from... ax_boost_thread.m4:33: AX_BOOST_THREAD is expanded from... configure.ac:39: the top level configure.ac:34: required file `build-aux/ar-lib' not found configure.ac:34: `automake --add-missing' can install `ar-lib' autoreconf: automake failed with exit status: 1 - David Eccles (gringer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688513: [experimental] soft lockup (CPU#1 stuck for stuck for Xs!) on Intel(R) Pentium(R) D CPU 2.80GHz
On 25.09.2012 19:06, Jonathan Nieder wrote: Do you remember what the first kernel you experienced this with was? Does 3.2.29-1 or newer from unstable have this problem as well? How about the 2.6.32.y kernel from squeeze? The problem actually still exists for 2.6.32 [linux-image-2.6.32-5-amd64], so it seems less likely to be something that can be discovered by a bisect. I've since run 8 passes of a memtest (~6 hours) with no failures, which has made me more convinced that it's a software issue. I suppose for a better comparison I'd need to leave it running for a week or so (without any freezing issues). In that case, I guess it's a 32-bit/64-bit issue. I'm considering reverting the system to a 32-bit kernel (it only has 1.5GB memory) because it's difficult to predict when the CPU freezes will happen, and I've had to hard-shutdown the computer a few times via the power button. Less curious, more frustrated, - David -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688513: linux-image-3.5-trunk-amd64: soft lockup (CPU#1 stuck for stuck for Xs!) on Intel(R) Pentium(R) D CPU 2.80GHz
Package: src:linux Version: 3.5.2-1~experimental.1 Severity: grave Justification: causes non-serious data loss Dear Maintainer, Since returning to NZ and reinstalling Debian unstable on my computer in March this year, I have had issues with my computer freezing about once per week. This seems to be due to both CPUs freezing, but not at the same time -- I get error messages about stuck CPUs prior to the computer becoming completely unusable. This is a data loss issue for me because the only fix I can use to get the computer working again is a reset, which can mean that cached data from recent work is not written to the hard drive. The issue had not previously impacted my desktop work too much, as long as any programs that I ran saved their state at reasonably frequent intervals or did not take more than a day or so to run. I have since replaced the computer with another system at my work, but now use the sytem at home as an experimental web server, where intermittent, difficult-to-repeat CPU freezes are a bit more of a problem for me. This was a system that had been kept in storage for about a year while I was in Germany, so I thought it might have been a hardware problem, but I've always had the thought of a software bug in the back of my head (this is my first report of the issue). Prior to my trip to Germany, I had been running Debian unstable fine (within expected limits) for about 5 years (although the installation was 32-bit rather than the current 64-bit version). I have tried to update the kernels in an attempt to fix this problem, to no avail. The current kernel is from experimental, because I am always hoping that the next version will fix the problem. There does not seem to be any relationship between anything obvious and the CPU freezes. Considering it might be a hardware issue, I gave the computer a good clean with no change in behaviour. A brief memcheck (one pass) seemed fine. It is possible that the issue ocurrs more frequently under high load, but that might just be because I'm more likely to be around the computer when it's doing more things at once. An example dump from syslog is shown below: Sep 23 17:22:51 assimilis kernel: [ 5448.148015] BUG: soft lockup - CPU#1 stuck for 22s! [nullmailer-send:8240] Sep 23 17:22:51 assimilis kernel: [ 5448.148021] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables mperf cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ppdev lp bnep rfcomm bluetooth rfkill crc16 binfmt_misc nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 mbcache jbd sha1_generic arc4 ecb ppp_mppe ppp_generic slhc loop fuse joydev hid_generic i915 iTCO_wdt iTCO_vendor_support video drm_kms_helper lpc_ich drm mfd_core snd_intel8x0 snd_ac97_codec snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer i2c_algo_bit rng_core snd soundcore ac97_bus evdev i2c_i801 i2c_core parport_pc parport psmouse dcdbas pcspkr serio_raw processor button thermal_sys xfs dm_mod sg sr_mod cdrom sd_mod crc_t10dif usb_storage usbhid hid uas microcode ata_generic uhci_hcd ata_piix ehci_hcd libata scsi_mod usbcore tg3 libphy usb_common [last unloaded: scsi_wait_scan] Sep 23 17:22:51 assimilis kernel: [ 5448.148139] CPU 1 Sep 23 17:22:51 assimilis kernel: [ 5448.148141] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables mperf cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative ppdev lp bnep rfcomm bluetooth rfkill crc16 binfmt_misc nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 mbcache jbd sha1_generic arc4 ecb ppp_mppe ppp_generic slhc loop fuse joydev hid_generic i915 iTCO_wdt iTCO_vendor_support video drm_kms_helper lpc_ich drm mfd_core snd_intel8x0 snd_ac97_codec snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer i2c_algo_bit rng_core snd soundcore ac97_bus evdev i2c_i801 i2c_core parport_pc parport psmouse dcdbas pcspkr serio_raw processor button thermal_sys xfs dm_mod sg sr_mod cdrom sd_mod crc_t10dif usb_storage usbhid hid uas microcode ata_generic uhci_hcd ata_piix ehci_hcd libata scsi_mod usbcore tg3 libphy usb_common [last unloaded: scsi_wait_scan] Sep 23 17:22:51 assimilis kernel: [ 5448.148236] Sep 23 17:22:51 assimilis kernel: [ 5448.148240] Pid: 8240, comm: nullmailer-send Not tainted 3.5-trunk-amd64 #1 Dell Inc. OptiPlex GX620 /0FH884 Sep 23 17:22:51 assimilis kernel: [ 5448.148246] RIP: 0010:[8107a576] [8107a576] do_raw_spin_lock+0x15/0x1b Sep 23 17:22:51 assimilis kernel: [ 5448.148257] RSP: :88005ae11d30 EFLAGS: 0202 Sep 23 17:22:51 assimilis kernel: [ 5448.148260] RAX: 0001 RBX: RCX: Sep 23 17:22:51 assimilis kernel: [ 5448.148263] RDX: RSI: 7f7a6edf74a4 RDI: ead6eae0 Sep 23 17:22:51 assimilis kernel: [ 5448.148265] RBP: 880054c1ed98 R08:
Bug#624492: grub-common: allow additional customisation before graphics mode is set
Package: grub-common Version: 1.99~rc1-13 Severity: wishlist I would like to try to get my eeepc 701 to start the grub menu with a screen resolution of 800x480 (the native resolution of the computer). This resolution is not available at grub startup, but various websites suggest that this resolution can be made available by running commands that utilise the 915resolution module: insmod 915resolution 915resolution 5c 800 480 16 I noticed that there is an option that I can put into /etc/default/grub, 'GRUB_PRELOAD_MODULES', that allows me to identify modules to be loaded before almost everything else (lines 32-34 in /etc/grub.d/00_header), but I can't find anything for additional commands to be run at a similar stage. While I can fix this by editing 00_header, that seems to go against the idea of how the grub.d files are set up. I can see three possible fixes to this: 1) Add a GRUB_PRELOAD_COMMANDS option to 00_header. This may be difficult if it is desirable to protect the script from bad code. 2) Split 00_header into two (or more) files. I think the header file should really only do basic configuration, and other files should do the bulk of the configuration. 3) Add code specifically for 915resolution that is parsed by 00_default and added to grub.cfg. For example: GRUB_915RES_MODES=5c:800x480x16 34:1024x600 I think the second option is more Debian, so it is my preferred option for fixing this bug. My rough proposal follows: 00_header: lines 1-77 (until save_env is determined) 02_display: lines 78-159 (until terminal_output) 04_themes: remainder (allows 05_debian_theme to work) My proposal would allow 01_ and 03_ scripts to be put in for setup before display configuration and theming respectively. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-common depends on: ii base-files 6.3 Debian base system miscellaneous f ii dpkg1.16.0.2 Debian package management system ii gettext-base0.18.1.1-3 GNU Internationalization utilities ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-11Embedded GNU C Library: Shared lib ii libdevmapper1.02.1 2:1.02.63-3 The Linux Kernel Device Mapper use ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib ii libfuse22.8.4-1.4Filesystem in USErspace library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages grub-common recommends: ii os-prober 1.46 utility to detect other OSes on a Versions of packages grub-common suggests: pn grub-emu none (no description available) pn multiboot-doc none (no description available) pn xorriso none (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#591815: Manpage not installed for acpi-support
That man page only appears to be in one of the packages after installation. I'd
guess that even though the manpage reference is there for acpi-support, it's not
being installed. An installation of acpi-support installs all three packages in
that source package (acpi-fakekey, acpi-support, acpi-support-base), but only
one link to the manpage is known about using dpkg:
# aptitude install acpi-support
The following NEW packages will be installed:
acpi-fakekey{a} acpi-support acpi-support-base{a}
0 packages upgraded, 3 newly installed, 0 to remove and 120 not upgraded.
Need to get 0B/91.1kB of archives. After unpacking 975kB will be used.
Do you want to continue? [Y/n/?]
Selecting previously deselected package acpi-fakekey.
(Reading database ... 261887 files and directories currently installed.)
Unpacking acpi-fakekey (from .../acpi-fakekey_0.137-3_i386.deb) ...
Selecting previously deselected package acpi-support-base.
Unpacking acpi-support-base (from .../acpi-support-base_0.137-3_all.deb) ...
Selecting previously deselected package acpi-support.
Unpacking acpi-support (from .../acpi-support_0.137-3_all.deb) ...
Processing triggers for man-db ...
Setting up acpi-fakekey (0.137-3) ...
Starting acpi_fakekey daemon...done.
Setting up acpi-support-base (0.137-3) ...
Setting up acpi-support (0.137-3) ...
$ dpkg -S 'acpi_fakekey'
acpi-fakekey: /usr/bin/acpi_fakekey
acpi-fakekey: /usr/sbin/acpi_fakekeyd
acpi-fakekey: /usr/share/man/man1/acpi_fakekey.1.gz
$ ls /usr/share/man/man?/acpi*
/usr/share/man/man1/acpi.1.gz/usr/share/man/man1/acpi_fakekey.1.gz
/usr/share/man/man8/acpi_listen.8.gz
/usr/share/man/man1/acpi_available.1.gz /usr/share/man/man8/acpid.8.gz
The weird thing is that both support and fakekey packages contain that man page
in their contents:
$ dpkg -c acpi-support-base_0.137-3_all.deb | grep man
$ dpkg -c acpi-support_0.137-3_all.deb | grep man
drwxr-xr-x root/root 0 2010-08-07 12:30 ./usr/share/man/
drwxr-xr-x root/root 0 2010-08-07 12:30 ./usr/share/man/man1/
-rw-r--r-- root/root 366 2010-08-07 12:30
./usr/share/man/man1/acpi_fakekey.1.gz
$ dpkg -c acpi-fakekey_0.137-3_i386.deb | grep man
drwxr-xr-x root/root 0 2010-08-07 12:30 ./usr/share/man/
drwxr-xr-x root/root 0 2010-08-07 12:30 ./usr/share/man/man1/
-rw-r--r-- root/root 366 2010-08-07 12:30
./usr/share/man/man1/acpi_fakekey.1.gz
If I delve a little deeper into dh_installman, it looks like the manpage for
acpi-fakekey is being overwritten by the manpage for acpi-support:
acpi-support-0.137$ dh_installman -v
man --recode UTF-8 ./acpi_fakekey\.1 acpi_fakekey\.1\.new
chmod 644 acpi_fakekey.1.new
mv -f acpi_fakekey.1.new acpi_fakekey.1
man --recode UTF-8 ./acpi_fakekey\.1 acpi_fakekey\.1\.new
chmod 644 acpi_fakekey.1.new
mv -f acpi_fakekey.1.new acpi_fakekey.1
I guess a check for this would be to alter another package, renaming the manpage
to acpi_fakekey.1 (or whatever), and see if it changes the installed manpage.
This seems like two bugs:
[1] acpi-support has acpi_fakekey.1 as its manpage
[2] dh_installman doesn't check to make sure it's not overwriting a man page
from another package
[2] is a potential problem, because it suggests that manpages are not checked
for filename clashes between packages, and it's possible for a manpage to be
replaced by a manpage for another package.
David Eccles (gringer)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591815: Bug only an issue for the same source package, installed at the same time?
I had a go at changing the manpage for acpi-support to cat.1, and it seems like there are safeguards to prevent that, so this is probably only a problem for packages that have the same source package. I guess it is assumed that whoever makes the source packages should really know better: # dpkg -i acpi-support_0.137-3_all.deb (Reading database ... 261993 files and directories currently installed.) Preparing to replace acpi-support 0.137-3 (using acpi-support_0.137-3_all.deb) ... Unpacking replacement acpi-support ... dpkg: error processing acpi-support_0.137-3_all.deb (--install): trying to overwrite '/usr/share/man/man1/cat.1.gz', which is also in package coreutils 8.5-1 Processing triggers for man-db ... Errors were encountered while processing: acpi-support_0.137-3_all.deb And curiously, also only a problem when installing the packages as a unit. When installing an unmodified acpi-support alone (after it had already been installed), dpkg complains about trying to overwrite files from another package: # dpkg -i acpi-support_0.137-3_all.deb (Reading database ... 261993 files and directories currently installed.) Preparing to replace acpi-support 0.137-3 (using acpi-support_0.137-3_all.deb) ... Unpacking replacement acpi-support ... dpkg: error processing acpi-support_0.137-3_all.deb (--install): trying to overwrite '/usr/share/man/man1/acpi_fakekey.1.gz', which is also in package acpi-fakekey 0.137-3 Processing triggers for man-db ... Errors were encountered while processing: acpi-support_0.137-3_all.deb David Eccles (gringer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588580: openshot: similar error about setup.py
Package: openshot Version: 1.1.3-1 Severity: normal I had a similar error about setup.py (see below). The PYTHONPATH fix mentioned previously allows me to run openshot. The setup.py script mentioned in this error message doesn't appear to exist, and I'm not convinced running a script called 'setup.py' from the current directory as root is the best suggestion in this case. $ dpkg -S setup.py | grep openshot || echo [No Results] [No Results] OpenShot (version 1.1.3) Process no longer exists: 13381. Creating new pid lock file. *** ERROR: MLT Python bindings failed to import *** *** ERROR: MLT Python bindings failed to import *** Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /usr/lib/pymodules/python2.6/openshot/classes/thumbnail.py, line 170, in run mlt.Factory().init() NameError: global name 'mlt' is not defined --- Error: OpenShot has not been installed in the Python path. (Both the site-packages and /usr/share/openshot folders were checked) Use the following command to install OpenShot: $ sudo python setup.py install -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-4-686 (SMP w/1 CPU core) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openshot depends on: ii librsvg2-common 2.26.3-1SAX-based renderer library for SVG ii melt 1:0.5.6-0.0 command line media player and vide ii python 2.6.5-6 interactive high-level object-orie ii python-glade22.17.0-2GTK+ bindings: Glade support ii python-gtk2 2.17.0-2Python bindings for the GTK+ widge ii python-mlt2 1:0.5.6-0.0 multimedia framework (python bindi ii python-pygoocanvas 0.14.1-1+b1 GooCanvas Python bindings ii python-support 1.0.9 automated rebuilding support for P ii python-xdg 0.19-2 Python library to access freedeskt Versions of packages openshot recommends: ii openshot-doc 1.1.3-1Help manual for OpenShot Video Edi openshot 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#551780: Alternate solution -- stop resolving in bash_completion
This bug maybe should be moved to avahi?
The problem is in /etc/bash_completion, or at least can be fixed by modifying
/etc/bash_completion (see attached diff), so it seems reasonable to call this a
bash-completion bug. Of course, it may be that avahi-browse isn't meant to block
while waiting for resolution, which would then be an avahi bug.
My attempt at patching this removes the resolve argument (-r) from avahi-browse,
so it just spits out cached data in a parseable format (-cp).
*** /etc/bash_completion2010-01-26 22:44:47.0 +1300
--- /etc/bash_completion.old2010-01-26 22:44:26.0 +1300
***
*** 1309,1315
if type avahi-browse /dev/null; then
if [ -n $(pidof avahi-daemon) ]; then
COMPREPLY=( ${comprep...@]} $(
! compgen -W $( avahi-browse -cp _workstation._tcp | \
grep ^= | cut -d\; -f7 | sort -u ) -- $cur ) )
fi
fi
--- 1309,1315
if type avahi-browse /dev/null; then
if [ -n $(pidof avahi-daemon) ]; then
COMPREPLY=( ${comprep...@]} $(
! compgen -W $( avahi-browse -cpr _workstation._tcp | \
grep ^= | cut -d\; -f7 | sort -u ) -- $cur ) )
fi
fi
Bug#563135: sign problem
whoops, there were a few '=' signs where there should have been '==' signs.
diff -ur gtetrinet-0.7.11/src/config.c gtetrinet-0.7.11-new/src/config.c
--- gtetrinet-0.7.11/src/config.c 2006-11-04 01:49:49.0 +1300
+++ gtetrinet-0.7.11-new/src/config.c 2009-12-31 18:29:29.0 +1300
@@ -62,6 +62,7 @@
GDK_Right,
GDK_Left,
GDK_Up,
+GDK_x,
GDK_Control_R,
GDK_Down,
GDK_space,
@@ -72,7 +73,19 @@
GDK_3,
GDK_4,
GDK_5,
-GDK_6
+GDK_6,
+GDK_y,
+GDK_h,
+GDK_n,
+GDK_u,
+GDK_j,
+GDK_m,
+GDK_i,
+GDK_k,
+GDK_comma,
+GDK_o,
+GDK_l,
+GDK_period,
};
guint keys[K_NUM];
@@ -268,6 +281,15 @@
else
keys[K_ROTRIGHT] = defaultkeys[K_ROTRIGHT];
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rotate_up, NULL);
+if (p)
+{
+ keys[K_ROTUP] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_ROTUP] = defaultkeys[K_ROTUP];
+
p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rotate_left, NULL);
if (p)
{
@@ -368,6 +390,114 @@
keys[K_SPECIAL6] = defaultkeys[K_SPECIAL6];
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall0, NULL);
+if (p)
+{
+ keys[K_L0] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L0] = defaultkeys[K_L0];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall1, NULL);
+if (p)
+{
+ keys[K_L1] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L1] = defaultkeys[K_L1];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall2, NULL);
+if (p)
+{
+ keys[K_L2] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L2] = defaultkeys[K_L2];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall3, NULL);
+if (p)
+{
+ keys[K_L3] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L3] = defaultkeys[K_L3];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall4, NULL);
+if (p)
+{
+ keys[K_L4] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L4] = defaultkeys[K_L4];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall5, NULL);
+if (p)
+{
+ keys[K_L5] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L5] = defaultkeys[K_L5];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall0, NULL);
+if (p)
+{
+ keys[K_R0] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R0] = defaultkeys[K_R0];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall1, NULL);
+if (p)
+{
+ keys[K_R1] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R1] = defaultkeys[K_R1];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall2, NULL);
+if (p)
+{
+ keys[K_R2] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R2] = defaultkeys[K_R2];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall3, NULL);
+if (p)
+{
+ keys[K_R3] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R3] = defaultkeys[K_R3];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall4, NULL);
+if (p)
+{
+ keys[K_R4] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R4] = defaultkeys[K_R4];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall5, NULL);
+if (p)
+{
+ keys[K_R5] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R5] = defaultkeys[K_R5];
+
/* Get the timestamp option. */
timestampsenable = gconf_client_get_bool (gconf_client,
/apps/gtetrinet/partyline/enable_timestamps, NULL);
@@ -517,6 +647,18 @@
}
void
+keys_rotate_up_changed (GConfClient *client,
+guint cnxn_id,
+GConfEntry *entry)
+{
+
+ client = client; /* Suppress compile warnings */
+ cnxn_id = cnxn_id; /* Suppress compile warnings */
+
+ keys[K_ROTUP] = gdk_keyval_to_lower (gdk_keyval_from_name
(gconf_value_get_string (gconf_entry_get_value (entry;
+}
+
+void
keys_rotate_right_changed (GConfClient *client,
guint cnxn_id,
GConfEntry *entry)
@@ -625,6 +767,150 @@
}
void
Bug#563135: Alternate reduced-press input method for gtetrinet
Package: gtetrinet
Version: 0.7.11
Severity: wishlist
Tags: patch
I would like to be able to use an alternate method for changing rotation and
selecting the drop column for gtetrinet. This would have three actions per drop,
each requiring a single keypress:
1) rotate piece to desired rotation
2) move piece to desired column
3) drop piece
Such an input method reduces the number of keypresses required to put pieces
into the ideal location, making the game a bit faster (although this alternative
method needs a fair amount of training to get used to).
I have attached a patch that does this. There are now 13 new keys that can be
configured:
* Rotate piece 180 degrees
* Move piece 0-5 blocks away from left wall (i.e. 6 keys)
* Move piece 0-5 blocks away from right wall (i.e. 6 keys)
The 180 degrees rotation is implemented as two left rotations, the move away
from walls are implemented as a twelve step shift to the respective wall, then
the required number of movements in the opposite direction, i.e. leftwall4: move
left 12, then right 4. In other words, the new keys are merely macros for
particular key sequences. This means that if there is a tall barrier in the
middle and the piece is going down one side, it can't jump over the barrier
(which should be impossible).
diff -ur gtetrinet-0.7.11/src/config.c gtetrinet-0.7.11-new/src/config.c
--- gtetrinet-0.7.11/src/config.c 2006-11-04 01:49:49.0 +1300
+++ gtetrinet-0.7.11-new/src/config.c 2009-12-31 18:29:29.0 +1300
@@ -62,6 +62,7 @@
GDK_Right,
GDK_Left,
GDK_Up,
+GDK_x,
GDK_Control_R,
GDK_Down,
GDK_space,
@@ -72,7 +73,19 @@
GDK_3,
GDK_4,
GDK_5,
-GDK_6
+GDK_6,
+GDK_y,
+GDK_h,
+GDK_n,
+GDK_u,
+GDK_j,
+GDK_m,
+GDK_i,
+GDK_k,
+GDK_comma,
+GDK_o,
+GDK_l,
+GDK_period,
};
guint keys[K_NUM];
@@ -268,6 +281,15 @@
else
keys[K_ROTRIGHT] = defaultkeys[K_ROTRIGHT];
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rotate_up, NULL);
+if (p)
+{
+ keys[K_ROTUP] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_ROTUP] = defaultkeys[K_ROTUP];
+
p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rotate_left, NULL);
if (p)
{
@@ -368,6 +390,114 @@
keys[K_SPECIAL6] = defaultkeys[K_SPECIAL6];
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall0, NULL);
+if (p)
+{
+ keys[K_L0] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L0] = defaultkeys[K_L0];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall1, NULL);
+if (p)
+{
+ keys[K_L1] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L1] = defaultkeys[K_L1];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall2, NULL);
+if (p)
+{
+ keys[K_L2] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L2] = defaultkeys[K_L2];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall3, NULL);
+if (p)
+{
+ keys[K_L3] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L3] = defaultkeys[K_L3];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall4, NULL);
+if (p)
+{
+ keys[K_L4] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L4] = defaultkeys[K_L4];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/leftwall5, NULL);
+if (p)
+{
+ keys[K_L5] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_L5] = defaultkeys[K_L5];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall0, NULL);
+if (p)
+{
+ keys[K_R0] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R0] = defaultkeys[K_R0];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall1, NULL);
+if (p)
+{
+ keys[K_R1] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R1] = defaultkeys[K_R1];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall2, NULL);
+if (p)
+{
+ keys[K_R2] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R2] = defaultkeys[K_R2];
+
+p = gconf_client_get_string (gconf_client,
/apps/gtetrinet/keys/rightwall3, NULL);
+if (p)
+{
+ keys[K_R3] = gdk_keyval_to_lower (gdk_keyval_from_name (p));
+ g_free (p);
+}
+else
+ keys[K_R3] = defaultkeys[K_R3];
+
+p = gconf_client_get_string (gconf_client,
