Bug#1040782: bug not present in 2.99.16
To help in narrowing this down, I installed the version from the experimental repo. I got 2.99.16. This does not appear to show the bug, so I guess it's a Debian packaging issue. "This is an unstable development release commit d3c5536" graeme@real:~/Documents/Remote/Bugs/Gimp/1040782$ apt-cache policy gimp gimp: Installed: 2.99.16-2 Candidate: 2.99.16-2 Version table: *** 2.99.16-2 100 1 https://deb.debian.org/debian experimental/main amd64 Packages 100 /var/lib/dpkg/status 2.10.34-1 500 500 http://ftp.uk.debian.org/debian unstable/main amd64 Packages
Bug#1040782: working with GIMP 2.10.30
In case it helps in narrowing it down. I have the wacom tablet connected via a USB switch. If I switch the hardware to a Kubuntu system running GIMP 2.10.30, it works fine. The failing system is a "dev box", so if you want me to try a number of versions (and give brief instructions) I can do that. As I said previously, the failing system just moved from bookwork to trixie, I'm afraid I didn't note the (working) gimp version prior to upgrade. -- Graeme
Bug#1040782: gimp: Using wacom tablet to chose menu crashes gimp
Package: gimp Version: 2.10.34-1 Severity: important X-Debbugs-Cc: none, Graeme Vetterlein Dear Maintainer, Open GIMP (wilber-big.jpg) using mouse select pencil, draw a line, change size (in menu) draw line. Repeat using wacom bamboo tablet . as soon as you try to change size, Gimp crashes (many other actions cause this abort, this is just a specific example (this is immediately after ugrading SID from bookwork to trixie) >From gimp crash report: ``` GNU Image Manipulation Program version 2.10.34 git-describe: GIMP_2_10_34 Build: unknown rev 0 for linux # C compiler # Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Debian 12.2.0-14) # Libraries # using babl version 0.1.106 (compiled against version 0.1.98) using GEGL version 0.4.46 (compiled against version 0.4.42) using GLib version 2.74.6 (compiled against version 2.74.5) using GdkPixbuf version 2.42.10 (compiled against version 2.42.10) using GTK+ version 2.24.33 (compiled against version 2.24.33) using Pango version 1.50.14 (compiled against version 1.50.12) using Fontconfig version 2.14.1 (compiled against version 2.14.1) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` > fatal error: Aborted Stack trace: ``` # Stack traces obtained from PID 24950 - Thread 24950 # [New LWP 24951] [New LWP 24952] [New LWP 24953] [New LWP 24954] [New LWP 24955] [New LWP 24956] [New LWP 24957] [New LWP 24958] [New LWP 24959] [New LWP 24961] [New LWP 25047] [New LWP 25073] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __GI___libc_read (nbytes=256, buf=0x7ffdb114eb30, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26 Id Target Id Frame * 1Thread 0x7f1fdfb84300 (LWP 24950) "gimp-2.10" __GI___libc_read (nbytes=256, buf=0x7ffdb114eb30, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26 2Thread 0x7f1fdf2856c0 (LWP 24951) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 3Thread 0x7f1fdea846c0 (LWP 24952) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 4Thread 0x7f1fd7fff6c0 (LWP 24953) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 5Thread 0x7f1fde2836c0 (LWP 24954) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 6Thread 0x7f1fdda826c0 (LWP 24955) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 7Thread 0x7f1fdd2816c0 (LWP 24956) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8Thread 0x7f1fdca806c0 (LWP 24957) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 9Thread 0x7f1fd6d516c0 (LWP 24958) "gmain" 0x7f1fe08709ef in __GI___poll (fds=0x5566263db0f0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 10 Thread 0x7f1fd65506c0 (LWP 24959) "gdbus" 0x7f1fe08709ef in __GI___poll (fds=0x5566263ee460, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 11 Thread 0x7f1fad5ff6c0 (LWP 24961) "async" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 12 Thread 0x7f1fa30146c0 (LWP 25047) "swap writer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 13 Thread 0x7f1fa38156c0 (LWP
Bug#1025453: Info received (additional information)
Actually it looks like it's coming up on its first decade https://bugzilla.kernel.org/show_bug.cgi?id=86311
Bug#1025453: additional information
The following may be helpful: 1: I am running this on bare matal (no KVM, vmware etc) 2: $cat /proc/cupinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz stepping : 3 microcode : 0x9 cpu MHz : 823.533 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_unknown bogomips : 6799.82 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 ...elided...
Bug#1025453: workaround
Having seen bookworm go to stable with this bug still present, I did some more digging. This comment: https://forums.debian.net/viewtopic.php?t=150032 Points at an earlier bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867548#52 And applying their workaround, my issue disappears: [ edit /etc/default/grub to add GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on,igfx_off" ] However reading the forum post, it appears they hit the issue on upgrading to "bullseye" I get the issue upgrading from "bullseye" to "sid (bookworm)". Now, for me, this was very much "Monkey See, Monkey do" I don't know what that line added to kernel boot args does, but: 1: Maybe it's avoiding something that broken ..or 2: It is the correct option that should be added I either case, something is broken. It works on one release, you upgrade, it breaks. My initial guess would be something in the initrd generation or grub choices is going wrong during the install process. Could somebody move this issue to a more sensible place (package) as it's unclear to me where the root problem lies (also tie to 867548 )
Bug#1025453: still in 0.3.67-1
I've switched to experimental , for : pipewire + libpipewire* $ apt-cache policy pipewire pipewire: Installed: 0.3.67-1 Candidate: 0.3.67-1 Version table: *** 0.3.67-1 800 1 https://deb.debian.org/debian experimental/main amd64 Packages 100 /var/lib/dpkg/status 0.3.65-3 500 500 http://ftp.uk.debian.org/debian unstable/main amd64 Packages 500 http://ftp.de.debian.org/debian sid/main amd64 Packages graeme@real:~/Documents/Remote/Bugs/22mar2023-pipewire-freedeskt>op$ So now 0.3.67-1 .. bug persists
Bug#1025453: Is there any update
Added to "pipewire" https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3110 On 20/03/2023 11:07, Dylan Aïssi wrote: Le sam. 18 mars 2023 à 14:51, graeme vetterlein a écrit : I, for one, have had no sound for the past 4 months. Not personally critical as it's an unstable dev system, not main dev machine. Do you have no sound at all or choppy sound like you said in [1]. Have you tried using speakers not connected via HDMI? I guess it is related to HDMI connection, can you fill a bug on the upstream bug tracker [2]? [1]https://bugs.debian.org/1025453#40 [2]https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
Bug#1025453: Is there any update
Indeed it was simply choppy. I (personally) have no sound because I had to turn it off, it was unlistenable. I don't have other "speakers" but I plugged in a set of headphones, I assume that's equivalent? Anyhow sound from the headphones was fine. (tested with mpv and Lxmusic) On 20/03/2023 11:07, Dylan Aïssi wrote: Le sam. 18 mars 2023 à 14:51, graeme vetterlein a écrit : I, for one, have had no sound for the past 4 months. Not personally critical as it's an unstable dev system, not main dev machine. Do you have no sound at all or choppy sound like you said in [1]. Have you tried using speakers not connected via HDMI? I guess it is related to HDMI connection, can you fill a bug on the upstream bug tracker [2]? [1] https://bugs.debian.org/1025453#40 [2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues
Bug#1025453: Is there any update
I see this is marked as the only "important" bug in pipewire. I, for one, have had no sound for the past 4 months. Not personally critical as it's an unstable dev system, not main dev machine. But I'm guessing this is being targeted as the new "sound system" in Debian 12 . Is it being worked on? Is there a major problem? I'm wondering if pipewire is no longer destined for "Debian 12" ? -- Graeme
Bug#1033021: flash-kernel: support for qnap TS-412
Package: flash-kernel Version: 3.79 Severity: minor Dear Maintainer, NB the System Information below is incorrect. I'm actually running an old stretch build here (buster would not install) but since it's working in stretch, I guess it's still be working in later releases. The file /usr/share/doc/flash-kernel/README.gz says: If you would like to see support for another device, please file a bug However I believe the QNAP TS-412 is already supported, so the README is simply out of date ? (I could be wrong, time may tell) -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-67-generic (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025453: I am the creator of #40 and I'm still seeing it
Sorry to have cause confusion here. I was pointed at 1024093 from elsewhere. When it seemed a good match but was still broken I added my 2 cents wroth. I didn't spot it was a virtual environment. Thanks to James for doing the admin of cloning the bug. It's now just over 5 weeks from my original comment and the behaviour is unchanged. I'll repeat my offer to run some tests, if somebody could suggest a good set. -- Graeme
Bug#1024160: base: Running XFCE under x2GO fails with grey screen
Indeed it does appear to fix it. 1: Did synaptic update (with libwnck-3-0 still pinned) [many updates unrelated to this] 2: logout/in via X2GO .. works 3: remove pin from synaptic and apt-mark unhold 4: synaptic update (it updates gir1.2-wnck-3.0 and libwnck-3-0 ) 5: Logout/in via x2go ...works 6: reboot 7: Login via x2go ...works 8: login via lightdm ... works So seems fixed. I'd actually looked at synaptic "latest version" recently and saw it was 43.0-3 ... but I mentally tagged that was "the version I had issues with :-( " For My Information, where could I have watched the upstream commits ? That might have caused me to notice it sooner? On 10/12/2022 17:02, Bernhard Übelacker wrote: Hello Graeme Vetterlein, I have reassigned the bug to package libwnck-3-0. Just later I saw that there was already a release: Changes: libwnck3 (43.0-3) unstable; urgency=medium . * Backport four upstream commits to fix Xfce X2Go sessions. (Closes: #1021685, #1025174) Is your issue fixed with this version? Kind regards, Bernhard
Bug#1024160: adding lib version
I realised I did not include the library name and version in the base text of my original report (it was in links) I keep checking my version against the "broken" version , so I end up having to follow links :-( So the failing version is : |libwnck-3-0:amd64 43.0-2|
Bug#1024093: still broken
I appreciate this has been marked closed , but I'm not seeing it fixed. This seemed such an basic bug, I'd assumed it would have been reported multiple times. with 0.3.60-1 it played video using smplayer but not mpv , firefox youtube was choppy . When run via x2go, videos would not play at all now with 0.3.60-3 , on native XFCE: mpv, smplayer, firefox+youtube are all choppy ... in fact I had to log out and back in to get any sound, when I tried to retest for this report. Via X2go: mpv fails to play at all, smplayer is smooth, and firefox+youtube is OK The audio is via an HDMI connection (same settup worked fine on buster) ...I get similar effects with .mp3 audio files, but I only did a few samples. smplayer = choppy mpv = choppy Parole Media Player = choppy Probably warrants some basic tests , which I'm happy to run , given a (human) script of some kind. XFCE desktop, HDMI connected speakers graeme@real:~$ apt-cache rdepends pipewire pipewire Reverse Depends: wireplumber xdg-desktop-portal-wlr xdg-desktop-portal-tests pipewire-media-session sxmo-utils gstreamer1.0-pipewire pipewire-v4l2 pipewire-tests pipewire-pulse pipewire-libcamera pipewire-jack pipewire-bin pipewire-bin pipewire-alsa libspa-0.2-modules libspa-0.2-modules libpipewire-0.3-modules libpipewire-0.3-modules libpipewire-0.3-0 gnome-remote-desktop graeme@real:~$ apt show pipewire 2> /dev/null | grep Version Version: 0.3.60-3 graeme@real:~$ apt show wireplumber 2> /dev/null | grep Version Version: 0.4.12-1+b1 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1024160: base: Running XFCE under x2GO fails with grey screen
Package: base Severity: important X-Debbugs-Cc: none, New Graeme Vetterlein Dear Maintainer, This issue is with XFCE (while running under X2GO) There are details at: https://gitlab.xfce.org/xfce/xfwm4/-/issues/678#note_59619 >From another system (kubuntu in this case) create an X2GO session to a server running Debian SID (see below) , open the session: Result you are left with grey window (the X root window) Repeat the same exercise using LXDE, it works fine. On the Debain Server # dpkg -i libwnck-3-0_3.36.0-1_amd64.deb # apt-mark hold libwnck-3-0 Repeat the XFCE session via X2GO, it works fine. There is a comment in https://gitlab.gnome.org/GNOME/libwnck/-/issues/154#note_1563621 Suggesting the offending change can be revereted without problem. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#746415: Still seeing the symptom
Well I pretty much stopped using gnome-terminal (due to this bug) so I've not been spotting changes. The symptoms seem to be the same, I guess the root cause may be different. $ gnome-terminal --version # GNOME Terminal 3.30.2 using VTE 0.54.2 +GNUTLS $ dpkg-query -l gnome-terminal WARNING: terminal is not fully functional - (press RETURN) Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii gnome-terminal 3.30.2-2 amd64 GNOME terminal emulator application Behaviour seems similar to the original post : $ env | grep LANG LANG=C (this is reduced from before) $ id uid=1001(guest) gid=1001(guest) groups=1001(guest) (Just for MY reference, running these as guest) $ gnome-terminal # Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached $ ...only the debug is no longer appearing (I assume due to https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/42 getting fixed? ) Following this I tried: $ export LC_ALL=en_GB.utf8 graeme@real:~$ locale LANG=en_GB.utf8 LANGUAGE= LC_CTYPE="en_GB.utf8" LC_NUMERIC="en_GB.utf8" LC_TIME="en_GB.utf8" LC_COLLATE="en_GB.utf8" LC_MONETARY="en_GB.utf8" LC_MESSAGES="en_GB.utf8" LC_PAPER="en_GB.utf8" LC_NAME="en_GB.utf8" LC_ADDRESS="en_GB.utf8" LC_TELEPHONE="en_GB.utf8" LC_MEASUREMENT="en_GB.utf8" LC_IDENTIFICATION="en_GB.utf8" LC_ALL=en_GB.utf8 graeme@real:~$ gnome-terminal # Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached Previously I assume it worked with a UTF8 based locale (from the context) -- Graeme
Bug#935336: jsvc on buster doesn't support the installable openjdk version
Package: jsvc Version: 1.0.15-8 Followup-For: Bug #935336 Dear Maintainer, Software supplied by Ubiquiti (Wifi routers) fails because of this bug. The bug was fixed in https://issues.apache.org/jira/browse/DAEMON-410 and so release 1.2.3 Annotated debug is: Mar 27 21:15:50 real unifi.init[7070]: user changed to 'unifi' Mar 27 21:15:50 real unifi.init[7070]: User 'unifi' validated Mar 27 21:15:50 real unifi.init[7070]: Attempting to locate Java Home in /usr/lib/jvm/java-11-openjdk-amd64 Mar 27 21:15:50 real unifi.init[7070]: Attempting to locate VM configuration file /usr/lib/jvm/java-11-openjdk-amd64/jre/lib/jvm.cfg Mar 27 21:15:50 real unifi.init[7070]: Attempting to locate VM configuration file /usr/lib/jvm/java-11-openjdk-amd64/lib/jvm.cfg Mar 27 21:15:50 real unifi.init[7070]: Found VM configuration file at /usr/lib/jvm/java-11-openjdk-amd64/lib/jvm.cfg Mar 27 21:15:50 real unifi.init[7070]: Found VM server definition in configuration GV> the file: /usr/lib/jvm/java-11-openjdk-amd64/lib/jvm.cfg: -server KNOWN -client IGNORE -zero KNOWN -dcevm KNOWN Mar 27 21:15:50 real unifi.init[7070]: Checking library /usr/lib/jvm/java-11-openjdk-amd64/jre/lib/amd64/server/libjvm.so Mar 27 21:15:50 real unifi.init[7070]: Checking library /usr/lib/jvm/java-11-openjdk-amd64/lib/amd64/server/libjvm.so Mar 27 21:15:50 real unifi.init[7070]: Cannot locate library for VM server (skipping) GV> it's here > /usr/lib/jvm/java-11-openjdk-amd64/lib/server/libjvm.so Appears to be this --> https://issues.apache.org/jira/browse/DAEMON-410 The patch is: --- src1/native/unix/native/location.c 2019-11-20 03:40:52.426012014 -0800 +++ src/native/unix/native/location.c 2019-11-20 03:41:53.705012149 -0800 @@ -118,6 +118,7 @@ "$JAVA_HOME/jre/lib/libjvm.so", "$JAVA_HOME/lib/classic/libjvm.so", "$JAVA_HOME/lib/client/libjvm.so", +"$JAVA_HOME/lib/server/libjvm.so", "$JAVA_HOME/lib/libjvm.so", "$JAVA_HOME/jre/bin/classic/libjvm.so", "$JAVA_HOME/jre/bin/client/libjvm.so" Which you can see does contain the correct path for java-11-openjdk . This is also broken/missing in later debian builds As a workaround, many users are installing old Java8 JREs and running ubuntu in a docker container -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jsvc depends on: ii libc6 2.28-10 ii libcommons-daemon-java 1.0.15-8 Versions of packages jsvc recommends: ii default-jre-headless [java2-runtime-headless] 2:1.11-71 ii openjdk-11-jre-headless [java2-runtime-headless] 11.0.9.1+1-1~deb10u2 jsvc suggests no packages. -- no debconf information
Bug#746415: Changing LANG is not a solution
Is this defect being addressed, It seems to have been important for 6 years? I am just hitting it in Debian buster (gdm3, gnome3) . I cannot set LANG= I must use LANG=C because it affects such things as sort order and only the C local has the semantic I need. $ dpkg -l gnome-terminal Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---=== ii gnome-terminal 3.30.2-2 amd64 GNOME terminal emulator application I actually hit a different (gnome-terminal) bug, but then hit this one while debugging that: $ env | grep LANG LANGUAGE=en_GB:en GDM_LANG=en_GB.UTF-8 LANG=en_GB.UTF-8 guest@real:~$ gnome-terminal # watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0) # watch_established: "/org/gnome/desktop/interface/" (establishing: 1) # watch_established: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 1) # watch_established: "/org/gnome/desktop/sound/" (establishing: 1) # watch_established: "/org/gnome/desktop/privacy/" (establishing: 1) # watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1) # watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1) # watch_established: "/org/gnome/desktop/a11y/" (establishing: 1) # watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0) # unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1) # watch_established: "/org/gnome/terminal/legacy/" (establishing: 0) ... then terminal starts root@real:~# cat /home/guest/set-C-locale update-locale LANG=C LANGUAGE root@real:~# . /home/guest/set-C-locale root@real:~# cat /etc/default/locale # File generated by update-locale LANG=C #LANGUAGE=en_GB:en logoff , logon again (gdm3 + gnome3) $ env | grep LANG LANGUAGE=en_GB:en GDM_LANG=C LANG=C $ gnome-terminal # watch_fast: "/org/gnome/desktop/interface/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/sound/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/privacy/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/wm/preferences/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 0, active: 0) # watch_fast: "/org/gnome/desktop/a11y/" (establishing: 0, active: 0) # watch_established: "/org/gnome/desktop/interface/" (establishing: 1) # watch_established: "/org/gnome/settings-daemon/peripherals/mouse/" (establishing: 1) # watch_established: "/org/gnome/desktop/sound/" (establishing: 1) # watch_established: "/org/gnome/desktop/privacy/" (establishing: 1) # watch_established: "/org/gnome/desktop/wm/preferences/" (establishing: 1) # watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1) # watch_established: "/org/gnome/desktop/a11y/" (establishing: 1) # Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached $ Setting LANG=C is required to work by various standards, many other programs in order to get valid support data require to be run in C locale. In my case I need emacs to be running under C locale ... so I cannot set it later e.g. in .bashrc -- Graeme
Bug#962224: lightdm does not source ~/.profile
Package: lightdm
Version: 1.26.0-4
Severity: normal
Tags: newcomer
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Having switched to lightdm from GDM3 (due to another bug in gdm3) I now find
~/.profile does
not run.
In order to debug this I created a clean user (new) called guest (pid=1001)
I modified ~/.profile and ~/.bash_profile to log their use (see attached log)
In summary the behaviour was:
gdm3 + cinnamon = Runs ~/.profile only
gdm3 + xfce = Runs ~/.profile only
gdm3 + gnome3 = Runs ~/.profile only
Switch to lioghtdm & reboot system
lightdm + cinnamon = Runs neither
lightdm + xfce = Runs neither
lightdm + gnome = Runs neither
lightdm + gnome(2nd version) = Runs neither
The doc @ https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/794315 points
to where this has been fixed in the past.
-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lightdm depends on:
ii adduser3.118
ii dbus 1.12.16-1
ii debconf [debconf-2.0] 1.5.71
ii libaudit1 1:2.8.4-3
ii libc6 2.28-10
ii libgcrypt201.8.4-5
ii libglib2.0-0 2.58.3-2+deb10u2
ii libpam-systemd [logind]241-7~deb10u4
ii libpam0g 1.3.1-5
ii libxcb11.13.1-2
ii libxdmcp6 1:1.1.2-3
ii lightdm-gtk-greeter [lightdm-greeter] 2.0.6-1
ii lsb-base 10.2019051400
Versions of packages lightdm recommends:
ii xserver-xorg 1:7.7+19
Versions of packages lightdm suggests:
ii accountsservice 0.6.45-2
ii upower 0.99.10-1
ii xserver-xephyr 2:1.20.4-1
-- debconf information:
* shared/default-x-display-manager: lightdm
lightdm/daemon_name: /usr/sbin/lightdm
$ head -20 ~/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
ENV="/tmp/${USER}.env"
rm -f ${ENV}
echo ".profile run at $(date)" > ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1
LOGON_TIME=$(date) export LOGON_TIME
$ head -20 ~/.bash_profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
ENV="/tmp/${USER}-bash.env"
rm -f ${ENV}
echo ".profile run at $(date)" > ${ENV}
pstree -glus $$>> ${ENV}
env>> ${ENV} 2>&1
LOGON_TIME=$(date) export LOGON_TIME
$
*** GDM3 + cinnamon
$ ls -l /tmp/*.env
-rw-rw-rw- 1 graeme users 462 Jun 4 18:37 /tmp/graeme-bash.env
-rw-r--r-- 1 graeme users 1226 Jun 4 18:37 /tmp/graeme.env
-rw-r--r-- 1 guest guest 839 Jun 4 18:42 /tmp/guest.env
$ id
uid=1001(guest) gid=1001(guest) groups=1001(guest)
$ cat /tmp/guest.env
.profile run at Thu 4 Jun 18:42:46 BST 2020
systemd(1)---gdm3(826)---gdm-session-wor(826)---gdm-x-session(8109,guest)---Xsession(8109)---pstree(8109)
USER=guest
LANGUAGE=en_GB:en
XDG_SEAT=seat0
XDG_SESSION_TYPE=x11
HOME=/home/guest
DESKTOP_SESSION=cinnamon
GTK_MODULES=gail:atk-bridge
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1001/bus
LOGNAME=guest
XDG_SESSION_CLASS=user
USERNAME=guest
XDG_SESSION_ID=25
WINDOWPATH=4
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GDM_LANG=en_GB.UTF-8
XDG_RUNTIME_DIR=/run/user/1001
DISPLAY=:0
LANG=en_GB.UTF-8
XDG_SESSION_DESKTOP=cinnamon
XAUTHORITY=/run/user/1001/gdm/Xauthority
SHELL=/bin/sh
GDMSESSION=cinnamon
QT_ACCESSIBILITY=1
XDG_VTNR=4
PWD=/home/guest
Bug#961935: gdm3 fails to display uid=501
Package: gdm3 Version: 3.30.2-3 Severity: important Tags: d-i Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I have just installed debian 10.4 . I opted to install multiple desktops including cinnamon, gnome3 and xfce I need to set my uid to 501 as I use NFSv3 an my NAS allocates normal users in the range 501 to 999 Two issues (possibly related) 1: My username does not appear as a choice on gdm3 (the documentation says all above 500 should) [ I cannot find a config setting to chnage this ] < https://help.gnome.org/admin/gdm/3.26/configuration.html.en#generalsessionconfig > 2. If I manually type my name and logon , using the "cog" to select say cinnamon, the I get cinnamon 2a If I log off & on again, I stoll get cinnamon 2b If I reboot, it goes back to gnome3 I created a new user (user666) $ sudo useradd -c "uid is 666" -m -u 666 user666 $ sudo passwd user666 New password: Retype new password: passwd: password updated successfully Then at GDM3 login: I turned on debug and saw: 4 matches for "Error" in buffer: gdm3.debug3 517:May 28 19:02:10 real gdm-password]: AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User666: Operation was cancelled 1313:May 28 19:04:53 real gdm-launch-environment]: AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User117: Operation was cancelled 1314:May 28 19:04:53 real gdm-launch-environment]: AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User117: Operation was cancelled 1531:May 28 19:05:26 real gdm-password]: AccountsService: Error calling GetAll() when retrieving properties for /org/freedesktop/Accounts/User666: Operation was cancelled If I were to guess, I'd say the limit had been set to 1000 , not 500 as per docs. But in anycase I'd like to override back to around 200. The lack of persistance of the the desktop session choice seem to affect users in the same pid range (<1000) -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.45-2 ii adduser 3.118 ii cinnamon [x-window-manager] 3.8.8-1 ii cinnamon-session [x-session-manager] 3.8.2-1 ii dconf-cli 0.30.1-2 ii dconf-gsettings-backend 0.30.1-2 ii debconf [debconf-2.0] 1.5.71 ii gir1.2-gdm-1.03.30.2-3 ii gnome-session [x-session-manager] 3.30.1-2 ii gnome-session-bin 3.30.1-2 ii gnome-settings-daemon 3.30.2-3 ii gnome-shell 3.30.2-11~deb10u1 ii gnome-terminal [x-terminal-emulator] 3.30.2-2 ii gsettings-desktop-schemas 3.28.1-1 ii libaccountsservice0 0.6.45-2 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcanberra-gtk3-00.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libgdm1 3.30.2-3 ii libglib2.0-0 2.58.3-2+deb10u2 ii libglib2.0-bin2.58.3-2+deb10u2 ii libgtk-3-03.24.5-1 ii libkeyutils1 1.6-6 ii libpam-modules1.3.1-5 ii libpam-runtime1.3.1-5 ii libpam-systemd241-7~deb10u4 ii libpam0g 1.3.1-5 ii librsvg2-common 2.44.10-2.1 ii libselinux1 2.8-1+b1 ii libsystemd0 241-7~deb10u4 ii libwrap0 7.6.q-28 ii libx11-6 2:1.6.7-1 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.13.1-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 10.2019051400 ii muffin [x-window-manager] 3.8.2-1 ii mutter [x-window-manager] 3.30.2-9~deb10u1 ii policykit-1 0.105-25 ii procps2:3.3.15-2 ii ucf
Bug#925282: fetchmail: the message [This account is currently not available] is ambigious
Package: fetchmail Version: 6.3.26-3 Severity: minor Tags: patch Dear Maintainer, I've just hit an "issue" WRT fetchmail, which I now relaise I hit about 10 years ago and didn't report (shame on me) the "fix" is a simple text edit so I hope you'll consider it. I was getting the message: reading message b...@mail..net:1 of 26 (16491 octets) #<...many stars elided...>*This account is currently not available. The way I was invoking it (as part of debugging, originally a cronjob[mail]) > sudo -u mail /usr/bin/fetchmail -f fetchmail-testrc -v -d0 Where fetchmail-testrc, said: poll mail.XXX.net tracepolls with protocol POP3 user box1 password options fetchall mda "/usr/bin/maildrop /etc/maildroprc.manual" Where /etc/maildroprc.manual had a complex config which split the mail into multiple users and invoked sendmail. So the code we have running is: fetchmail maildrop sendmail (exim4) All these have suid/sgid. The users involved are: mail Debian-exim fetchmail courier So I'm getting a message "This account is currently not available" . It might be coming from any of the above programs, the user might be any of the above users. I've just spent another 2 days working on this (presumably longer 10 years ago) before resolving it using "diff(1)" of my old system. But the error was: passwd> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin The fix was: # usermod -s /bin/bash mail So, my proposal :-) This would have been vastly quicker to find and fix had the message read: Instead of: "This account is currently not available" The text: "fetchmail: The account "mail" is currently not available" or better (if it's true) "fetchmail: The account "mail" does not have a valid shell (e.g. bash)" (my guess is you don't directly issue this message) -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fetchmail depends on: ii adduser 3.115 ii debianutils 4.8.1.1 ii libc6 2.24-11+deb9u4 ii libcomerr21.43.4-2 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libk5crypto3 1.15-1+deb9u1 ii libkrb5-3 1.15-1+deb9u1 ii libssl1.1 1.1.0j-1~deb9u1 ii lsb-base 9.20161125 Versions of packages fetchmail recommends: ii ca-certificates 20161130+nmu1+deb9u1 Versions of packages fetchmail suggests: ii exim4-daemon-light [mail-transport-agent] 4.89-2+deb9u3 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail [Errno 13] Permission denied: '/etc/default/fetchmail' -- no debconf information
Bug#766786: close of bug
In the three years since raising this bug, it looks like I've removed the VM in question. If I install another KVM it will probably be stretch so not a valid comparison. So I can’t see a sensible course other than closing it. -- Graeme
Bug#845563: apt-get update which ends up in grub-probe loops near Stack.pm uninitialized value
On 25/11/16 10:47, David Kalnischkies wrote:
Control: reassign -1 debconf 1.5.56
(version number is a guess from the apt/stable version)
On Thu, Nov 24, 2016 at 04:45:35PM +, Graeme Vetterlein wrote:
In brief. If I attempt to build a docker container using apt-get install , and
that process kicks off a grub-probe. The probe
fails (because we are in a container) not a surprise. However this causes
apt-get install to loop, presumably in the grub specific
setup scripts.
apt has no "setup scripts" and no grub specific pieces. The packages
which are installed carry them with them (if any) and hence any bug with
them is a bug for them, not for the tool unfortunately enough to be
tasked with running them (= dpkg ← apt ← user).
So, reassigning to … debconf (which is another tool tasked by others
with doing stuff…) as "uninitialized value" sounds bad and I have no
idea if it is debconfs or grubs fault…
yes | apt-get install --force-yes --allow-unauthenticated -y lttng-modules-dkms || echo
"Ignore failure, hope that's OK"
Thanks for the nightmares tonight!
Really, that is some very scary commandline. Are you really sure that
you want (whatever package actually) so desperately that you completely
ignore security AND destroy your system (okay, its a container, but
still) for it? With destroying your system you might be able to live,
but I guess you want to use the container for something later on… bad if
an attacker has already infected it with rootkits due to that command.
Also, there are better ways to answer dpkg-conffile questions and to let
debconf pick the default option than to run 'yes' over them. I can't
give blank advice on that as it depends on what you want to do and stuff
but I would highly suggest looking into it! Some pointers:
DEBIAN_FRONTEND=noninteractive and dpkg --force-conf{new,old,def}.
David,
Probably not as bad as you fear. This actual container I don't want
(it'll be deleted unused)
I produced it just to show the bug. The container I produced used
several private repos only.
Authentication did not work with these. If there is rogue code in there
, it's already inside the company
adding it to a container would be the least of our problems :-)
I'm only doing this to reproduce a build environment used by another
group. Once I have it working I'll be moving to
a more up-to-date distro (this was wheezy) .
As an interesting aside. I built this OK in an LXC container. I assume
this is because the way you build an LXC container
has you manually running apt-get at the command line (so stdin is my
tty) . I think this is an issue in Docker because
it requires to run "unattended" in a script. I'm guessing as Docker
popularity grows more of these kind of thing will turn up.
(this is my personal email, I'll forward your notes to work and read the
hints there, thanks for those)
Anway: On to the actual bug:
... < elided>.
debconf: falling back to frontend: Teletype
Creating config file /etc/default/grub with new version
grub-probe: error: cannot find a device for / (is /dev mounted?).
grub-probe: error: cannot find a device for /boot (is /dev mounted?).
grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
Configuring grub-pc
---
You chose not to install GRUB to any devices. If you continue, the boot loader
may not be properly configured, and when this computer next starts up it will
use whatever was previously in the boot sector. If there is an earlier version
of GRUB 2 in the boot sector, it may be unable to load modules or handle the
current configuration file.
If you are already using a different boot loader and want to carry on doing so,
or if this is a special environment where you do not need a boot loader, then
you should continue anyway. Otherwise, you should install GRUB somewhere.
Continue without installing GRUB?
Use of uninitialized value $_[1] in join or string at
/usr/share/perl5/Debconf/DbDriver/Stack.pm line 111.
grub-probe: error: cannot find a device for / (is /dev mounted?).
grub-probe: error: cannot find a device for /boot (is /dev mounted?).
grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?).
Use of uninitialized value $_[1] in join or string at
/usr/share/perl5/Debconf/DbDriver/Stack.pm line 111.
You chose not to install GRUB to any devices. If you continue, the boot loader
may not be properly configured, and when this computer next starts up it will
use whatever was previously in the boot sector. If there is an earlier version
of GRUB 2 in the boot sector, it may be unable to load modules or handle the
current configuration file.
If you are already using a different boot loader and want to carry on doing so,
or if this is a special environment where you do not need a boot loader, then
you should continue anyway. Otherwise, you should install GRUB somewhere.
Continue without installing GRUB?
grub-probe: error: cannot find
Bug#845563: apt-get update which ends up in grub-probe loops near Stack.pm uninitialized value
Package: apt Version: 1.0.9.8.3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: -- /etc/apt/preferences -- # D109394: See $MISC/linux-install/common/wheezy/etc/apt/preferences for # the reason why Pin-Priority for later releases is being left in # here even though they've been removed from etc/apt/sources.list # The idea of the Pin-Priority for later releases is to allow # people to install packages from those releases with apt-get -t . # This is based on the file from squeeze so the Pin-Priority's are set # in a similar manner to squeeze. # We could have left that out or set APT::Default-Release # in apt.conf but let's keep it all in one place. Package: * Pin: release a=unstable Pin-Priority: 50 Package: * Pin: release n=jessie Pin-Priority: 990 Package: * Pin: release n=jessie-updates Pin-Priority: 990 Package: * Pin: release n=jessie-backports Pin-Priority: 980 -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii debian-archive-keyring 2014.3 ii gnupg 1.4.18-7+deb8u3 ii libapt-pkg4.12 1.0.9.8.3 ii libc6 2.19-18+deb8u6 ii libgcc1 1:4.9.2-10 ii libstdc++6 4.9.2-10 apt recommends no packages. Versions of packages apt suggests: pn apt-doc ii aptitude0.6.11-1+b1 ii dpkg-dev1.17.27 ii python-apt 0.9.3.12 ii synaptic0.81.2 ii wajig 2.17 -- no debconf information I've not included my host /etc/apt/sources.list etc, because this is occuring in a (Docker) container and these are the wrong ones. In brief. If I attempt to build a docker container using apt-get install , and that process kicks off a grub-probe. The probe fails (because we are in a container) not a surprise. However this causes apt-get install to loop, presumably in the grub specific setup scripts. Note apt-get install is being run with -y --allow-unauthenticated . I can work around the problem using: yes | apt-get install --force-yes --allow-unauthenticated -y lttng-modules-dkms || echo "Ignore failure, hope that's OK" The 'y' being piped in resolves it. In detail: docker build -t isbroken -f BrokenDockerfile . Sending build context to Docker daemon 347.6 kB Step 1 : FROM debian:wheezy ---> 337681dc4ec4 Step 2 : MAINTAINER gvetterl...@xxx.com ---> Using cache ---> 377d0e4374da Step 3 : COPY sources.list /etc/apt/sources.list.d/HSP.list ---> Using cache ---> e44be478c8f1 Step 4 : COPY 98localmirror /etc/apt/apt.conf.d/98localmirror ---> Using cache ---> 4b62b3256281 Step 5 : RUN apt-get update ---> Running in ffa7376b5160 ... < elided>. debconf: falling back to frontend: Teletype Creating config file /etc/default/grub with new version grub-probe: error: cannot find a device for / (is /dev mounted?). grub-probe: error: cannot find a device for /boot (is /dev mounted?). grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?). Configuring grub-pc --- You chose not to install GRUB to any devices. If you continue, the boot loader may not be properly configured, and when this computer next starts up it will use whatever was previously in the boot sector. If there is an earlier version of GRUB 2 in the boot sector, it may be unable to load modules or handle the current configuration file. If you are already using a different boot loader and want to carry on doing so, or if this is a special environment where you do not need a boot loader, then you should continue anyway. Otherwise, you should install GRUB somewhere. Continue without installing GRUB? Use of uninitialized value $_[1] in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 111. grub-probe: error: cannot find a device for / (is /dev mounted?). grub-probe: error: cannot find a device for /boot (is /dev mounted?). grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?). Use of uninitialized value $_[1] in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 111. You chose not to install GRUB to any devices. If you continue, the boot loader may not be properly configured, and when this computer next
Bug#696795: indeed it does seem to be fixed in Jessie
(got prompted by bug tracking system to respond) On Jessie: The .odt file in the defect, exported as a PDF, opens fine in Evince AFYI: The Original PDF (attached in the defect) also opens and reads fine in Evince (also several other PDF viewers) So I assume it was a fix to Evince rather than LibreOffice. -- Graeme
Bug#784158: cinnamon: GUI logons with cinnamon + lightdm do not source either /etc/profile or ~/.profile
Package: cinnamon Version: 2.2.16-5 Severity: important Tags: newcomer patch Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? My ~/.profile (I believe the default jessie one) was not being sourced as $PATH was being set incorrectly * What exactly did you do (or not do) that was effective (or ineffective)? I added trace to /etc/profile and ~/.profile (symlinked ~/.bash_profile to ~/.profile) * What was the outcome of this action? trace did not trigger * What outcome did you expect instead? I expected BOTH scripts to be executed at a GUI logon. Looking back @ wheezy, I see work was done in /etc/gdm/Xsession. I took the relevant section of that file and used it to create: /etc/X11/Xsession.d/70fix_lightdm_gpv: # GPV: 2-May-2015, lightdm + cinnamon forgets to source ANY profiles!! # First read /etc/profile and .profile test -f /etc/profile . /etc/profile test -f $HOME/.profile . $HOME/.profile # Second read /etc/xprofile and .xprofile for X specific setup test -f /etc/xprofile . /etc/xprofile test -f $HOME/.xprofile . $HOME/.xprofile # Local Variables: # mode: shell-script # sh-indentation: 2 # indent-tabs-mode: nil # End: # vim:set ai et sts=2 sw=2 tw=80: This caused both /etc/profile and ~/.profile to get executed and so the wheezy behaviour was restored. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cinnamon depends on: ii caribou 0.4.15-1 ii cinnamon-common 2.2.16-5 ii cinnamon-control-center 2.2.11-4 ii cinnamon-desktop-data2.2.3-3 ii cinnamon-screensaver 2.2.4-6 ii cinnamon-session 2.2.2-5 ii cinnamon-settings-daemon 2.2.4.repack-7 ii cjs 2.2.2-2 ii cups-pk-helper 0.2.5-2+b1 ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii gir1.2-accountsservice-1.0 0.6.37-3+b1 ii gir1.2-caribou-1.0 0.4.15-1 ii gir1.2-clutter-1.0 1.20.0-1 ii gir1.2-cmenu-3.0 2.2.0-3 ii gir1.2-cogl-1.0 1.18.2-3 ii gir1.2-gconf-2.0 3.2.6-3 ii gir1.2-gdkpixbuf-2.0 2.31.1-2+b1 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.42.0-2.2 ii gir1.2-gnomebluetooth-1.03.14.0-2 ii gir1.2-gnomedesktop-3.0 3.14.1-1 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-gtkclutter-1.01.6.0-1 ii gir1.2-javascriptcoregtk-3.0 2.4.8-2 ii gir1.2-meta-muffin-0.0 2.2.6-4 ii gir1.2-networkmanager-1.00.9.10.0-7 ii gir1.2-nmgtk-1.0 0.9.10.0-2 ii gir1.2-pango-1.0 1.36.8-3 ii gir1.2-polkit-1.00.105-8 ii gir1.2-soup-2.4 2.48.0-1 ii gir1.2-upowerglib-1.00.99.1-3.2 ii gir1.2-webkit-3.02.4.8-2 ii gkbd-capplet 3.6.0-1 ii gnome-icon-theme-symbolic3.12.0-1 ii gnome-session-bin3.14.0-2 ii gnome-settings-daemon3.14.2-3 ii gnome-themes-standard3.14.2.2-1 ii gsettings-desktop-schemas3.14.1-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18 ii libcairo21.14.0-2.1 ii libcanberra0 0.30-2.1 ii libcinnamon-menu-3-0 2.2.0-3 ii libcjs0 2.2.2-2 ii libclutter-1.0-0 1.20.0-1 ii libcogl-pango20 1.18.2-3 ii libcogl-path20 1.18.2-3 ii libcogl201.18.2-3 ii libcroco30.6.8-3+b1 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgirepository-1.0-11.42.0-2.2 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglib2.0-0 2.42.1-1 ii libgstreamer1.0-0
Bug#766786: gdm3: XDMCP connections to Jessie+gdm3 fail after a few seconds, while Jessie+xdm work fine.
Package: gdm3
Version: 3.4.1-8
Severity: important
Dear Maintainer,
This is being reported from a wheezy box, however the problem is unique to
jessie
(I'll try to extract the strings this tool seems to have generated [from the
wrong system)
root@vjessie:/mnt# uname -a
Linux vjessie 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux
root@vjessie:/mnt# dpkg -l | grep xdm
ii libxdmcp6:amd64 1:1.1.1-1amd64X11 Display
Manager Control Protocol library
ii xdm 1:1.1.11-1 amd64X display manager
root@vjessie:/mnt# dpkg -l | grep gdm
ii gdm33.14.0-1 amd64GNOME Display
Manager
ii gir1.2-gdm3 3.14.0-1 amd64GObject
introspection data for the GNOME Display Ma
ii libgdm1 3.14.0-1 amd64GNOME Display
Manager (shared library)
This is an issue with jessie but not wheezy.
XDMCP connections to Jessie+gdm3 fail after a few seconds, while Jessie+xdm
work fine.
Environment:
real machine (DNS name= real.home) runs Fedora20 , and qemu+kvm.
Virtual machines exist (e.g vdebain.home [wheezy] , vjessie.home )
Normal usage would be on real.home on another console (ALT-F3 etc) start:
X :2 -query 10.116.1.53 (address of vjessie)
If vjessie is running xdm , this works fine. If vjessie runs gdm3 it works for
about a minute, then just keeps dropping back to black X sreen (with X cursor)
SETUP:
On jessie:
install xdm, choose xdm as the default display manger.
Edit /etc/X11/xdm/xdm.config: (comment out the disable requestPort]
! Comment out this line if you want to manage X terminals with xdm
! GPV (previously was NOT commented) DisplayManager.requestPort:0
*restart
root@vjessie:/etc/X11/xdm# lsof -i:177
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xdm 906 root4u IPv6 1923 0t0 UDP *:xdmcp
From real.home :
ALT-F3
X :2 -query vjessie.home
On ALT-F1, an xmd logon screen appears.
After giving userid+password, a jessie screen (need to authenticate to manage
color managed console)
pops up and requires a passsword [ this is new and does not happen in wheezy ]
after authenticating
a normal desktop appears and works fine.
On jessie, do:
dpkg-reconfigure xdm
And choose gmd3
start-stop-daemon: pid value must be a number greater than 0
Try 'start-stop-daemon --help' for more information.
*restart*
Get gdm3 logon, after giving password, you get prompted with jessie screen (need
to authenticate to manage color managed console) , after authenticating, you
get a normal
jessie (gdm) desktop. Start an xterm and wait a minute or so. You get dropped
back to a plain black
X terminal (cursor is big X).
from this point on, after switching to another console (one real.home),
about once a minute , it switches back to
ALT-F1 and the blank X terminal. This pattern repeats.
In vjessie:/var/log/messages: there are messages about out of video memory
(which may well relate to what is happening)
Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Out of video memory: Could not
allocate 4378332 bytes
Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: - 0th attempt
But **NOTE** these messages are on vjessie.home. This is an XDMCP type login,
so the Xterminal is on real
..home where there are NO
messages. The virtual machine (vjessie) had a QXL display with 64Mb ... note
qxl_surface in the above message.
I wonder if gdm is attepting to use the wrong display?
Using gmd3 via SPICE, seems to work fine (wheezy was very poor in this mode)
but it is something like 100 times faster using XDMCP.
Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: - OOM at 1109 986 24 (= 3280422
bytes)
Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Cache contents: null null null null
null null null null null null null null null null null null null null null null
null nu\
ll null null null null null null null null null null null null null null null
null null null null null null null null null null null 339 333 330 350 338
343 336\
355 1015 354 739 976 1016 977 1011 1003 total: 16
Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Out of video memory: Could not
allocate 4378332 bytes
Oct 25 18:33:57 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1)
Oct 25 18:34:22 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1)
Oct 25 18:34:38 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1)
But **NOTE** these messages are on vjessie.home. This is an XDMCP type login,
so the Xterminal is on real.home where there are NO
messages. The virtual machine (vjessie) had a QXL display with 64Mb ... note
qxl_surface in the above message.
I wonder if gdm is attepting to use the wrong display?
Using gmd3 via SPICE, seems to work fine (wheezy was very poor in this mode)
but it is something like 100 times faster using XDMCP.
{ using reportbug has mad a bit a mess of this
Bug#766786: To avoid the artefacts produced by using bugreporter
I'll attach the original test file I created and attempted to move to the wheezy box, in groups of 4-5 lines: -- Graeme root@vjessie:/mnt# uname -a Linux vjessie 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux root@vjessie:/mnt# dpkg -l | grep xdm ii libxdmcp6:amd64 1:1.1.1-1amd64X11 Display Manager Control Protocol library ii xdm 1:1.1.11-1 amd64X display manager root@vjessie:/mnt# dpkg -l | grep gdm ii gdm33.14.0-1 amd64GNOME Display Manager ii gir1.2-gdm3 3.14.0-1 amd64GObject introspection data for the GNOME Display Ma ii libgdm1 3.14.0-1 amd64GNOME Display Manager (shared library) This is an issue with jessie but not wheezy. XDMCP connections to Jessie+gdm3 fail after a few seconds, while Jessie+xdm work fine. Environment: real machine (DNS name= real.home) runs Fedora20 , and qemu+kvm. Virtual machines exist (e.g vdebain.home [wheezy] , vjessie.home ) Normal usage would be on real.home on another console (ALT-F3 etc) start: X :2 -query 10.116.1.53 (address of vjessie) If vjessie is running xdm , this works fine. If vjessie runs gdm3 it works for about a minute, then just keeps dropping back to black X sreen (with X cursor) SETUP: On jessie: install xdm, choose xdm as the default display manger. Edit /etc/X11/xdm/xdm.config: (comment out the disable requestPort] ! Comment out this line if you want to manage X terminals with xdm ! GPV (previously was NOT commented) DisplayManager.requestPort:0 *restart root@vjessie:/etc/X11/xdm# lsof -i:177 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xdm 906 root4u IPv6 1923 0t0 UDP *:xdmcp From real.home : ALT-F3 X :2 -query vjessie.home On ALT-F1, a xmd logon screen appears. After giving userid+password, a jessie screen (need to authenticate to manage color managed console) pops up and requires a passsword [ this is new and does not happen in wheezy ] after authenticating a normal desktop appears and works fine. On jessie, do: dpkg-reconfigure xdm And choose gmd3 start-stop-daemon: pid value must be a number greater than 0 Try 'start-stop-daemon --help' for more information. *restart* Get gdm3 logon, after giving password, you get prompted with jessie screen (need to authenticate to manage color managed console) , after authenticating, you get a normal jessie (gdm) desktop. Start an xterm and wait a minute or so. You get dropped back to a plain black X terminal (cursor is big X). ...from this point on, after switching to another console (one real.home), about once a minute , it switches back to ALT-F1 and the blank X terminal. This pattern repeats. In vjessie:/var/log/messages: there are messages about out of video memory (which may well relate to what is happening) Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Out of video memory: Could not allocate 4378332 bytes Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: - 0th attempt Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: - OOM at 1109 986 24 (= 3280422 bytes) Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Cache contents: null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null 339 333 330 350 338 343 336 355 1015 354 739 976 1016 977 1011 1003 total: 16 Oct 25 18:33:53 vjessie gdm-Xorg-:0[3495]: Out of video memory: Could not allocate 4378332 bytes Oct 25 18:33:57 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1) Oct 25 18:34:22 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1) Oct 25 18:34:38 vjessie gdm-Xorg-:0[3495]: qxl_surface_create: Bad bpp: 1 (1) But **NOTE** these messages are on vjessie.home. This is an XDMCP type login, so the Xterminal is on real.home where there are NO messages. The virtual machine (vjessie) had a QXL display with 64Mb ... note qxl_surface in the above message. I wonder if gdm is attepting to use the wrong display? Using gmd3 via SPICE, seems to work fine (wheezy was very poor in this mode) but it is something like 100 times faster using XDMCP.
Bug#714100: xserver-xorg-input-evdev: no mouse wheel in spice enabled KVM guest and spice-vdagent running
I am seeing this on: wheezy running inside a KVM (on fedora20): Poking around with ximput. I discovered movements of my mouse were being seen in wheezy VM as tablet. The VM config (in virtual Machine Manager) did indeed have a tablet defined. I deleted this tablet (and also a 2nd mouse created while banging my head against the wall WRT this bug) and using xinput inside wheezy I saw a new 'tablet appear' Testing using xinput I can see that my mouse events are appearing on this tablet and not on the ExPS/2 Generic Explorer Mouse If I stop spice-vdagent , the spice vdagent tablet disappears, mouse input then appears on ExPS/2 Generic Explorer Mouse and the mouse wheel starts to work (appears as buttons 4 5) root@vdebian:~# xinput Virtual core pointerid=2[master pointer (3)] Virtual core XTEST pointer id=4[slave pointer (2)] ImExPS/2 Generic Explorer Mouse id=8[slave pointer (2)] Virtual core keyboard id=3[master keyboard (2)] Virtual core XTEST keyboard id=5[slave keyboard (3)] Power Buttonid=6[slave keyboard (3)] AT Translated Set 2 keyboardid=7[slave keyboard (3)] ACPI Virtual Keyboard Deviceid=9[slave keyboard (3)] root@vdebian:~# service spice-vdagent start [ ok ] Starting Agent daemon for Spice guests: spice-vdagent. root@vdebian:~# xinput Virtual core pointerid=2[master pointer (3)] Virtual core XTEST pointer id=4[slave pointer (2)] ImExPS/2 Generic Explorer Mouse id=8[slave pointer (2)] spice vdagent tabletid=10[slave pointer (2)] - NEW Virtual core keyboard id=3[master keyboard (2)] Virtual core XTEST keyboard id=5[slave keyboard (3)] Power Buttonid=6[slave keyboard (3)] AT Translated Set 2 keyboardid=7[slave keyboard (3)] ACPI Virtual Keyboard Deviceid=9[slave keyboard (3)] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734294: maildrop compiled with trusted user setting which seem to reduce security
Package: maildrop
Version: 2.5.5-2
Severity: wishlist
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I am trying to use maildrop tacked onto the back of fetchmail(1) as in:
... options fetchall mda /usr/bin/maildrop -d testing
This is reading what is in effect a multidrop mailbox, usinsg maildrop(1) config
to replace the lack of envelope information
* What exactly did you do (or not do) that was effective (or
ineffective)?
I run fetchmail as the user 'fetchmail' for reasons of security.
The -d option will not work on debain build of maildrop (as it lacks u+s bit)
if I add u+s , -d is now allowed BUT fetchmail (user) gets the message:
You are not a trusted user
Doing strings(1) on /usr/bin/maildrop seems to suggest the compiled in
trusted users
are 'mail root and daemon' .
1: I don't see these names documented
2: There is no option to maildrop to reveal which optiosn were used in compile
3: The Normal way to get this to work would be to run fetchmail as root
(trusted user + no need for u+s)
but exposes me to the obvious risk ... I run fetmail(1) because I (like many
otheres) don't want to risk an incomming SMTP
* What was the outcome of this action?
* What outcome did you expect instead?
4: It would help if this were runtime configurable (e.g. /etc/maildrop.conf) so
I could decide who was trusted.
*** End of the template - remove these lines ***
-- System Information:
Debian Release: 7.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: armel (armv5tel)
Kernel: Linux 3.0.4 (PREEMPT)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages maildrop depends on:
ii courier-authlib 0.63.0-6+b1
ii libc62.13-38
ii libgcc1 1:4.6.3-1
ii libgdbm3 1.8.3-11
ii libpcre3 1:8.30-5
ii libstdc++6 4.6.3-1
Versions of packages maildrop recommends:
ii exim4 4.80-7
ii exim4-daemon-light [mail-transport-agent] 4.80-7
maildrop suggests no packages.
-- Configuration Files:
/etc/maildroprc changed:
logfile /var/log/maildrop/$LOGNAME.log
ECHO=/bin/echo
MAIL=/usr/bin/mail
REFORMAIL=/usr/bin/reformail
SPAMHEADER=X-WB-spam:
MAILDIR=$HOME/mail
SPAM=${MAILDIR}/spam
if (/^X-Spam-Flag:\s+Y/)
to $SPAM
if (/^Subject:.*-SPAM-/)
to $SPAM
if (/^X-pn-pstn: Spam\s+[12345]/)
to $SPAM
if (/^TO.*donotsend*/)
to $SPAM
if (/^TO.*graeme@vetterlein.com/)
to $SPAM
-- 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#696417: may well be unrelated
... but in case other folks get here , due to google matches. I suspect the reason CUPS was reporting these messages and failing (and also testprnt was failing) was lack of real memory. The print sever is running on a DreamPlug , without swap and I think it was running out f real memory. Clue was , when restarting cups I was getting cannot fork type message (for KID3) and it really looked like fork(2) was failing ... ulimit was high ... so my guess was resource consumption ... e.g. memeory. -- I guess some better log entries would help ... if that is what is happening during normal print (not restart) -- Graeme -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696417: I'm seeing very similar messages from CUPS
This causes all cloudprint jobs to fail (+ others): (.e.g. print test page) 1: lp /etc/hosts works 2: lp /rtmp/hosts.ps ( postscript version of file) 3: lp /rtmp/hosts.pdf ( pdf version of file) all work However the 'print test page of cups , fails. The log /var/log/cups/error_log says: E [23/Feb/2013:22:08:57 +] [Job 32] PDF file is damaged - attempting to reconstruct xref table... W [23/Feb/2013:22:09:02 +] failed to CreateProfile: org.freedesktop.ColorManager.AlreadyExists:profile id 'brother-Gray..' already exists W [23/Feb/2013:22:09:02 +] failed to CreateDevice: org.freedesktop.ColorManager.AlreadyExists:device id 'cups-brother' already exists E [23/Feb/2013:22:09:02 +] [Job 32] Job stopped due to filter errors; please consult the error_log file for details. D [23/Feb/2013:22:09:02 +] [Job 32] The following messages were recorded from 22:08:57 to 22:09:02 elided... D [23/Feb/2013:22:09:02 +] [Job 32] GPL Ghostscript 9.05 (2012-02-08) D [23/Feb/2013:22:09:02 +] [Job 32] Copyright (C) 2010 Artifex Software, Inc. All rights reserved. D [23/Feb/2013:22:09:02 +] [Job 32] This software comes with NO WARRANTY: see the file PUBLIC for details. D [23/Feb/2013:22:09:02 +] [Job 32] Error: /undefined in Error: D [23/Feb/2013:22:09:02 +] [Job 32] Operand stack: D [23/Feb/2013:22:09:02 +] [Job 32] D [23/Feb/2013:22:09:02 +] [Job 32] Execution stack: D [23/Feb/2013:22:09:02 +] [Job 32] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- D [23/Feb/2013:22:09:02 +] [Job 32] Dictionary stack: D [23/Feb/2013:22:09:02 +] [Job 32] --dict:1166/1684(ro)(G)-- --dict:1/20(G)-- --dict:87/200(L)-- D [23/Feb/2013:22:09:02 +] [Job 32] Current allocation mode is local D [23/Feb/2013:22:09:02 +] [Job 32] Last OS error: No such file or directory D [23/Feb/2013:22:09:02 +] [Job 32] GPL Ghostscript 9.05: Unrecoverable error, exit code 1 D [23/Feb/2013:22:09:02 +] [Job 32] renderer exited with status 1 Is this an indication that cups are also using obsolete code? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566091: applied patch and build .deb package.
I applied this patch to lenny libpoppler3. Patch applied without errors. Rebuilt deb (new version No created ... libpoppler3_0.8.7-3.2_i386.deb ) Patched .deb managed to print the large image which would not print before. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566091: confirm , this affects lenny
I have been hit by this (64K array in ghostscript) in an up-to-date lenny system. (Print was done on ubuntu system but print server runs Debian-Lenny) # dpkg -l | grep poppler ii libpoppler-glib3 0.8.7-3 PDF rendering library (GLib-based shared library) ii libpoppler3 0.8.7-3 PDF rendering library ii poppler-utils0.8.7-3 PDF utilitites (based on libpoppler) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512234: chnage in behaviour
In what I suspect is a consequence of fixing this, I have noted the following change in behaviour in Lenny (updated today 20Jun2009) I have a machine with three Ethernet ports. ethA, ethB, ethC (not their real names BTW) ethA is connected to the outside world 192.168.X.253 (sorry about the X ,... don't want to make it too easy for the script kiddies) ethB is inward facing an has a different subnet I have the following: BrowseAddress @LOCAL And I have recently started getting messages from my firewall: Jun 20 07:42:19 localhost kernel: ATTACK via ethA IN=ethA OUT= MAC= SRC=192.168.X.253 DST=192.168.X.255 LEN=217 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=197 I will change my entry to: BrowseAddress @IF(ethB) But just FYI ... I suspect the behaviour has changed here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497050: trace of hang
I added a set -x into the script: /etc/init.d/module-init-tools The hang appears at line #56 # Loop over every line in /etc/modules. grep '^[^#]' $MODULES_FILE | \ while read module args; do Here [ $module ] || continue load_module $module $args done The obvious suggesting is that grep is not writing and not exiting. However I note I'm able to use ctrl-C to interrupt this ... suggesting I have a controlling TTY which I would not have expected. If I do ctrl-C this , later scripts also hang .. eventually I start getting problems with script failing -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497050: Cleaning up ifupdown hangs at startup
I am at this exact point Since kernel 2.6.26-2-686 the problem reappeared on my system. But now, the next line (loading kernel modules) also appears. The system completely hangs, I have to press the reset-button My kernel is: 2.6.26-2-486 Hand at 50% of the time Cleaning up ifupdown loading kernel modules ... hand ... needs hardware reset to fix. Numlock not working ... however keyboard echoes on screen . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
