Bug#1081253: closed by Andreas Metzler (Re: Bug#1081253: exim4-config: Upgrage exim4-config (4.96-15+deb12u5) reset dc_local_interfaces)
Thanks for that. I'd suggest the man page for this is somewhat lacking in detail: dc_local_interfaces List of IP addresses the Exim daemon should listen on. If this is left empty, Exim listens on all interfaces. Sets macro MAIN_LOCAL_INTERFACES only if there is a non-empty value. vs: dc_local_interfaces List of IP addresses and port numbers the Exim daemon should listen on. of the form []:;[address>]:;... ** If this is explicitly set to empty (dc_local_interfaces='') Exim listens on all interfaces. If this is not explicitly set, a default using localhost will be used. Sets macro MAIN_LOCAL_INTERFACES only if there is a non-empty value. (I suspect the above is not the full story , it's what I've gleaned though trial an error) **Poor meta syntax on my part since '[' is literal while '<' is meta syntax ... I'm guessing there is a better "house style" On 10/09/2024 18:03, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the exim4-config package: #1081253: exim4-config: Upgrage exim4-config (4.96-15+deb12u5) reset dc_local_interfaces It has been closed by Andreas Metzler. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Andreas Metzler by replying to this email.
Bug#1081253: exim4-config: Upgrage exim4-config (4.96-15+deb12u5) reset dc_local_interfaces
Package: exim4-config Version: 4.96-15+deb12u5 Severity: normal Dear Maintainer, I ran synantic , which applied the update: exim4-config (4.96-15+deb12u5) then rebooted the system I had previously REMOVED all settings of dc_local_interfaces in /etc/exim4/update-exim4.conf.conf Following a the reboot, SMTP was only listening on the localhost interface Examining the files , I discovered the line: dc_local_interfaces='127.0.0.1 ; ::1' Had been added to /etc/exim4/update-exim4.conf.conf ( and a regen run) FYI: I had previously set dc_local_interfaces . However I needed the file to be portable between 2 systems ( the mail gateway is xbox.home which is a CNAME for ybox.home or zbox.home...alternates on Debian releases) the interface names differ between these 2 systems. -- Package-specific info: Exim version 4.96 #2 built 09-Jul-2024 08:53:35 Copyright (c) University of Cambridge, 1995 - 2018 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2022 Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS TLS_resume move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP PIPECONNECT PRDR PROXY Queue_Ramp SOCKS SPF SRS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot external plaintext spa tls Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file # # GPV notes: # 1: Not set /etc/mailname (still says zbox.home) because we use dc_readhost (below) to rewite it # 2: Need to run update-exim4.conf # 3: The syntax of the dc_local_interfaces is poorly documented (lots of trial & error) (lsof confirms it's listening) # # Who WhenWhat # GPV 27feb19 Copied dreamplug version, chnaged 116 to 117 # GPV 01Mar19 Changed to 0.0.0.0 to ensure it listens on all the interfaces (can do better, some ports on some) # GPV 03Mar19 0.0.0.0 is too dangerous, because guys coming in from outside can access SMTP # GPV 29MAr20 New VIGOR DSL router can send email (SMTP) so also allow just this one device on the 192.168 LAN (web suggests both ; and : as seperator..using :) # GPV 28Jan22 Merged into ybox default, looks like it's identical to zbox file # GPV 13Aug22 Changed everything from 151 to 152 and from zbox to ybox # GPV 15Mar23 Made a guess that adding received_headers_max = 50 would add it to /var/lib/exim4/config.autogenerated (and in turn have an effect) # GPV 15Mar23 That does not work, try ading to a files under /etc/exim4/conf.d/ (in fact add that line here prevents regeneration) # GPV 12Apr24 Moved back to zbox...annoyingly dc_local_interfaces cannot use actaul interface names (which would wold great) but must use IP addresses dc_eximconfig_configtype='smarthost' dc_other_hostnames='ybox.home;home;wellesleydrive;xbox.home;zbox.home' #dc_local_interfaces='[10.117.128.152]:587;[10.117.0.152]:587;[127.0.0.1]:587;[10.117.0.152]:25;[127.0.0.1]:25;[192.168.1.152]:25' #dc_local_interfaces='[10.117.0.152]:587;[127.0.0.1]:587;[10.117.0.152]:25;[127.0.0.1]:25;[192.168.1.152]:25;[192.168.1.152]:587' # We are using a tempory address for the moment, it will need to move #dc_local_interfaces='[0.0.0.0]:587 # Missed out so it listens on all IF dc_readhost='vetterlein.com' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='10.117.0.0/16 : 192.168.1.254/32' dc_smarthost='smtp.forwardemail.net' CFILEMODE='644' dc_use_split_config='true' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:zbox.home # /etc/default/exim4 EX4DEF_VERSION='' # who whenwhat # GPV 11aug didn't copy the zbox version OR the installed version, instead followed advice in comments # # 'combined' - one daemon running queue and listening on SMTP po
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 0x7f1fa38
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 XDG_DATA_DIRS=/home/guest/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:
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&tips 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.
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 st
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: 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#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
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 ... 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