Bug#1052376: possible solution
Hello, The issue you are reporting can be fixed with patches from Bug#1052050. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052050 Mikhail Kshevetskiy
Bug#1052050: multiple problem with GTK3 enabled
Package: lxpanel Version: 0.10.1-4 Severity: important Tags: patch X-Debbugs-Cc: ChangZhuo Chen (陳昌倬) There are a lot of issues with GTK3 version of lxpanel that makes it almost unusable. The following patches required to apply to fix an issues: * 02-Correct-icon-grid-width-under-GTK3.-Fixes-Github-29.patch * 03-Correct-panel-size-under-GTK3.-Fixes-Sourceforge-773.patch * 04-Support-HiDPI-on-GTK-3.patch * 05-Highlight-selected-workspace-in-pager.patch * 06-fix-alsa-volume-issue.patch * 07-Fix-division-by-zero-with-broken-batteries.patch * 08-Use-XkbRF_GetNamesProp-instead-of-xkb_symbols.patch This patches was taken from https://github.com/lxde-continued/lxpanel.git. You may look there for more patches/details. Mikhail Kshevetskiy -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxpanel depends on: ii libasound2 1.2.9-2 ii libc62.37-8 ii libcairo21.17.8-3 ii libcurl3-gnutls 8.2.1-2 ii libfm-gtk3-4 1.3.2-4 ii libfm-modules1.3.2-4 ii libfm4 1.3.2-4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.78.0-1 ii libgtk-3-0 3.24.38-5 ii libiw30 30~pre9-14 ii libkeybinder-3.0-0 0.3.2-1.1 ii libmenu-cache3 1.1.0-1.1 ii libpango-1.0-0 1.51.0+ds-2 ii libwnck-3-0 43.0-3 ii libx11-6 2:1.8.6-1 ii libxkbfile1 1:1.1.0-1 ii libxml2 2.9.14+dfsg-1.3 ii lxmenu-data 0.1.5-2.1 ii lxpanel-data 0.10.1-4 Versions of packages lxpanel recommends: ii foot [x-terminal-emulator] 1.15.3-1 ii gnome-flashback [notification-daemon] 3.49.1-1+b1 ii gnome-shell [notification-daemon] 44.4-1 ii gnome-terminal [x-terminal-emulator]3.49.99-1 ii konsole [x-terminal-emulator] 4:22.12.3-1 ii libnotify-bin 0.8.2-1 ii mate-notification-daemon [notification-daemon] 1.26.0-1 ii mate-terminal [x-terminal-emulator] 1.26.1-1 ii pavucontrol 5.0-2 ii plasma-workspace [notification-daemon] 4:5.27.7-2 ii xfce4-notifyd [notification-daemon] 0.8.2-1 ii xfce4-terminal [x-terminal-emulator]1.1.0-1 ii xkb-data2.38-2 ii xterm [x-terminal-emulator] 384-1 Versions of packages lxpanel suggests: ii dillo [www-browser]3.0.5-7+b1 ii firefox-esr [www-browser] 115.2.0esr-1 ii konqueror [www-browser]4:22.12.3-2 ii links [www-browser]2.29-1 ii lynx [www-browser] 2.9.0dev.12-1 -- no debconf information >From 3c1ad6bc7c8b4b3ba66c04e6e10aa741f028ba75 Mon Sep 17 00:00:00 2001 From: Ben Walsh Date: Mon, 7 Feb 2022 07:02:05 + Subject: [PATCH] Correct icon-grid width under GTK3. Fixes Github #29. --- src/icon-grid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/icon-grid.c b/src/icon-grid.c index 2177971e..5948fee6 100644 --- a/src/icon-grid.c +++ b/src/icon-grid.c @@ -392,7 +392,7 @@ static void panel_icon_grid_get_preferred_width(GtkWidget *widget, } panel_icon_grid_size_request(widget, ); if (minimal_width) -*minimal_width = requisition.width; +*minimal_width = ig->constrain_width ? 2 : requisition.width; if (natural_width) *natural_width = requisition.width; } -- 2.40.1 >From 12576de7b83c634437217e23d74954070a1be2d5 Mon Sep 17 00:00:00 2001 From: Ben Walsh Date: Sat, 6 Jun 2020 10:38:15 +0100 Subject: [PATCH] Correct panel size under GTK3. Fixes Sourceforge #773. --- src/panel.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/panel.c b/src/panel.c index 45188dbe..2b5fc9be 100644 --- a/src/panel.c +++ b/src/panel.c @@ -293,6 +293,12 @@ lxpanel_get_preferred_height (GtkWidget *widget, if (natural_height) *natural_height = requisition.height; } + +static GtkSizeRequestMode +lxpanel_get_request_mode (GtkWidget *widget) +{ +return GTK_SIZE_REQUEST_CONSTANT_SIZE; +} #endif static void lxpanel_size_allocate(GtkWidget *widget, GtkAllocation *a) @@ -413,6 +419,7 @@ static void lxpanel_class_init(PanelToplevelClass *klass) #if GTK_CHECK_VERSION(3, 0, 0) widget_class->get_preferred_width = lxpanel_get_preferred_width; widget_class->get_preferred_height = lxpanel_get_preferred_height; +widget_class->get_request_mode = lxpanel_get_request_mode; #else widget_class->size_request = lxpanel_size_request; #en
Bug#953903: smbnetfs: Switch from deprecated to
fixed in smbnetfs-0.6.2 On Sat, 14 Mar 2020 18:41:45 +0100 Guillem Jover wrote: > Package: smbnetfs > Version: 0.6.1-1 > Severity: important > User: a...@packages.debian.org > Usertags: libattr-drop-attr-xattr-header > > Hi! > > This package uses the deprecated header (from libattr) > instead of the one provided now by glibc . > > The former header has been removed in upstream libattr, but got > reintroduced in Debian to avoid breakage just before the Debian buster > freeze. But I'd like to be able to remove it in Debian too, so that > the interface can be synced with upstream. > > It looks like this the only header used by this package from libattr, > so you should be able to drop the dependency on libattr entirely, as > glibc should be providing all that is needed now. > > Thanks, > Guillem
Bug#860716: shim fails to load MokManager (mmx64.efi) in the case of self-signed grub
On Sat, 23 Mar 2019 18:05:23 + Steve McIntyre wrote: > I'm hoping that our current set of packages will fix this bug, as > we've moved to a much newer upstream version of shim which includes > the commit you point at. Once we have our new shim signed with the > Microsoft CA, could you retry your test and confirm please? I just checked shim-signed=1.30+15+1533136590.3beb971-5 from unstable. The bug was fixed. Thanks a lot!
Bug#860716: shim fails to load MokManager (mmx64.efi) in the case of self-signed grub
On Sat, 23 Mar 2019 18:05:23 + Steve McIntyre wrote: > I'm hoping that our current set of packages will fix this bug, as > we've moved to a much newer upstream version of shim which includes > the commit you point at. Once we have our new shim signed with the > Microsoft CA, could you retry your test and confirm please? yes, I'll retest it.
Bug#860716: shim fails to load MokManager (mmx64.efi) in the case of self-signed grub
Package: shim Version: 0.9+1474479173.6c180c6-1 Severity: important I test shim-signed with qemu in secure boot environment. Here is the steps to reproduce a problem: 1) install shim, shim-signed, qemu and ovmf packages 2) get EnrollDefaultKeys.efi from https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/os/Packages/e/edk2-ovmf-20170209git296153c5-3.fc27.noarch.rpm 3) create a efi_test directory with shim binaries, grub and EnrollDefaultKeys.efi files mkdir efi_test cp /usr/lib/shim/{shimx64,mmx64,fbx64}.efi.signed efi_test/ rename 's/[.]signed$//' efi_test/* cp /boot/efi/EFI/debian/grubx64.efi efi_test/[this step is significant] cp EnrollDefaultKeys.efi efi_test/ [see step (2)] 4) so we have in efi_test/ LANG=C ls -la efi_test/ drwxr-xr-x 2 kl kl4096 Apr 19 12:10 . drwxr-xr-x 5 kl kl4096 Apr 19 11:52 .. -rw-r--r-- 1 kl kl 20032 Apr 19 11:55 EnrollDefaultKeys.efi -rw-r--r-- 1 kl kl9184 Apr 19 12:05 NvVars -rw-r--r-- 1 kl kl 72144 Apr 19 11:52 fbx64.efi -rwxr-xr-x 1 kl kl 121856 Apr 19 12:10 grubx64.efi -rw-r--r-- 1 kl kl 1168464 Apr 19 12:05 mmx64.efi -rw-r--r-- 1 kl kl 1169528 Apr 19 11:52 shimx64.efi 5) run qemu with ovmf firmware qemu-system-x86_64 -m 1024 -enable-kvm -machine q35,smm=on,accel=kvm \ -bios /usr/share/ovmf/OVMF.fd \ -drive media=disk,file=fat:rw:efi_test 6) import microsoft keys and enable secure boot (from EFI shell) Shell> fs0: FS0:\> EnrollDefaultKeys.efi info: SetupMode=1 SecureBoot=0 SecureBootEnabled=0 CustomMode=0 VendorKeys=1 info: SetupMode=0 SecureBoot=1 SecureBootEnabled=1 CustomMode=0 VendorKeys=0 info: success 7) reboot virtual machine (from EFI shell) FS0:\> reset 8) run shim (from EFI shell) Shell> fs0: FS0:\> shimx64.efi 9) expected result: MokManager (mmx64.efi) will be started 10) actual result: Verification failed: (15) Access Denied Failed to load image: Access Denied start_image() returned Access Denied start_image() returned Access Denied and we back to EFI shell. Thus it's not possible to install user keys or add user loader to trusted binary database. -- The following upsteram patch will resolve a problem: https://github.com/rhinstaller/shim/commit/9f2c83e60e0758c3db387eebaed3f306ad6214a8 PS: This bug affects ubuntu as well. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF8, LC_CTYPE=ru_RU.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#845989: [Pkg-privacy-maintainers] Bug#845989: marked as done (browser can't be downloaded because of invalid SSL certificate)
Hello, look like the problem is caused by missing "DigiCert SHA2 High Assurance Server CA" certificate on my debian testing system. (I check the same on other computer with debian stable and it was OK). Look below and pay attention to messages: 1) unable to get local issuer certificate 2) Verify return code: 20 (unable to get local issuer certificate) This results in failing of python OpenSSL library and finished by "You may be under attack" message during initial installation of torbrowser. kl@flywind:~$ openssl s_client -connect dist.torproject.org:443 CONNECTED(0003) depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/C=US/ST=Massachusetts/L=Cambridge/O=The Tor Project, Inc./ CN=*.torproject.org i:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert High Assurance EV Root CA --- Server certificate -BEGIN CERTIFICATE- MIIFaTCCBFGgAwIBAgIQDGnVmapHXfa3m9oYQq3WQTANBgkqhkiG9w0BAQsFADBw MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz dXJhbmNlIFNlcnZlciBDQTAeFw0xNjA0MTUwMDAwMDBaFw0xOTA1MjkxMjAwMDBa MHQxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRIwEAYDVQQH EwlDYW1icmlkZ2UxHjAcBgNVBAoTFVRoZSBUb3IgUHJvamVjdCwgSW5jLjEZMBcG A1UEAwwQKi50b3Jwcm9qZWN0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALcjOe3IaIUn5YEOnAAM+uIlKm0HyHUaR6rwU0m5YhdSV8DRGUB80Q67 zkIbutTMbEla8KpPSqsK/FShSXhLWB6Hv5UV2jR6/Pzxi8QaLMMAuLT5oHCkR6Jn LFZrUtPq50RmhYfg15kwosmEzPqLa3NDcK5tpTX5F48DvBT+0aCZQLndKGzVhiJI pEJdfTc69b1i4xGyhzp4ChUFDtmK9MRZFRvDFl4ZaVBe2haw/+1kemGwh5UuaD+P DqTJl+xwQdUCrKWBgwnOVLJKqrp2/Yc0mkkTFXqdUD1BS+wgvCDi64f7ndyyTQgb 8IWoWEeF6KHbiFZLVR/puH64cbyRF8cCAwEAAaOCAfkwggH1MB8GA1UdIwQYMBaA FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBSCJgjxEylVNBS0j4Adcbhg 2ktBzDArBgNVHREEJDAighAqLnRvcnByb2plY3Qub3Jngg50b3Jwcm9qZWN0Lm9y ZzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC MHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEy LWhhLXNlcnZlci1nNS5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNv bS9zaGEyLWhhLXNlcnZlci1nNS5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZn gQwBAgIwgYMGCCsGAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au ZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2Vy dC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNV HRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQCwURSDN25h03L4cN8+FFi6ZbzP OxIh8GgLKljF2nO/qW8gjKIOUgNizf99lsnn7YaYPCr8W9IZQBp64aWsWwuWZ3w8 bRhklFCmgHhDFeLCqmScYwxYlCmSL2qRe8Dus4t8Axse7LEni6KcOFA3Dtssc3MA jv30cEvGJru0mcogoMh8O04hmWZfC1EiyBLDDb5mBhijtMN+SbNQSr53mZWTgMXh luVXp48Z8RTrOdLJ03ArAh2gfpOLUz3eGmynpTFPz+l3V3yRHyoeWFiZUbm0ePnx 1HyeNR3onMNJC/tbYIBNoz/tIEPpFqJ1P3AT8q+uy/OQR4DEoG3f3Syq1pBG -END CERTIFICATE- subject=/C=US/ST=Massachusetts/L=Cambridge/O=The Tor Project, Inc./ CN=*.torproject.org issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/ CN=DigiCert SHA2 High Assurance Server CA --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3283 bytes and written 302 bytes Verification error: unable to get local issuer certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 610A3292E75EEFA38CA322D9C34ECA27C18D2E02E8200DD9DA8009BB4E99B654 Session-ID-ctx: Master-Key: F285EAAFB2AAE5CA3E495A1C8FE7D216CA9CADD366212077D823940DF9B4831C6E967B0C4989E75FBEE35877ADE5F015 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: - 3f d5 f2 67 6e 36 33 ab-8d 21 f1 68 0a cd 70 73 ?..gn63..!.h..ps 0010 - 5b 59 e8 6d 55 ec 18 71-fa 58 0f 19 3f b6 0f d8 [Y.mU..q.X..?... 0020 - af b1 95 57 8d fb b6 bc-49 09 7a 4b 7e 11 b0 96 ...WI.zK~... 0030 - 8c f3 6f 7e cd db 2e 40-2c 59 d7 5c 60 85 fa 78 ..o~...@,Y.\`..x 0040 - 93 2b 5c a1 63 e2 3e 28-e8 e1 7a 09 c7 34 ed 09 .+\.c.>(..z..4.. 0050 - 4e d0 54 82 ab cd 7e 35-e1 ee 3b 34 40 b1 e8 2e N.T...~5..;4@... 0060 - 19 2b 5b 3f b6 ca 36 8f-a1 e7 fe fa ff 99 db ff .+[?..6. 0070 - 3f 2b bb 59 bc 91 d0 0d-2e a9 3b 86 e8 6e 05 11 ?+.Y..;..n.. 0080 - f6 fc 5b c3 af 75 16 1f-f7 00 63 ab c3 97 6f 89 ..[..uc...o. 0090 - f8 bb be 16 f2 13 d9 5c-4d 62 23 4f c3 3c c1 b0 ...\Mb#O.<.. 00a0 - 70 c2 ad cc 54 e9 3e
Bug#845989: browser can't be downloaded because of invalid SSL certificate
Package: torbrowser-launcher Version: 0.2.6-2 Severity: grave Tags: upstream Trying to start torbrowser for the first time produce the following message The SSL certificate served by https://www.torproject.org is invalid! You may be under attack. After that the program terminate. Running it from terminal results in the following console output: Tor Browser Launcher By Micah Lee, licensed under MIT version 0.2.6 https://github.com/micahflee/torbrowser-launcher Downloading over Tor Downloading and installing Tor Browser for the first time. Downloading https://dist.torproject.org/torbrowser/update_2/release/Linux_x86_64-gcc3/x/en-US Download error: [] -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF8, LC_CTYPE=ru_RU.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages torbrowser-launcher depends on: ii ca-certificates 20161102 ii gnupg2.1.16-2 ii python-gtk2 2.24.0-5.1 ii python-lzma 0.5.3-3 ii python-parsley 1.2-1 ii python-psutil4.3.1-1 ii python-twisted 16.5.0-1 ii python-txsocksx 1.15.0.2-1 pn python:any ii wmctrl 1.07-7 Versions of packages torbrowser-launcher recommends: ii tor 0.2.8.9-1 Versions of packages torbrowser-launcher suggests: pn apparmor pn python-pygame -- no debconf information
Bug#737233: smbnetfs: Unknown libsmbclient version error
Thanks for report. It will be fixed in next release. I am working on it. Unfortunately i have no access to testing environment anymore... Mikhail On Fri, 31 Jan 2014 16:19:58 + George B. i93.b...@gmail.com wrote: Package: smbnetfs Version: 0.5.3b-1 Severity: minor Hello, I get this error when running the program: --- WARNING: Unknown libsmbclient version: 4.1.4-Debian SMBNetFS may not work as expected. --- Everything appears to still work, so setting severity to minor. Thanks, George -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-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 Versions of packages smbnetfs depends on: ii libc6 2.17-97 ii libfuse2 2.9.2-4 ii libglib2.0-0 2.36.4-1 ii libgnome-keyring0 3.8.0-2 ii libsmbclient 2:4.1.4+dfsg-3 Versions of packages smbnetfs recommends: ii fuse 2.9.2-4 smbnetfs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685479: Intel gma500 graphics module (gma500_gfx) is missing
Package: linux-image-3.5-trunk-amd64 Version: 3.5.2-1~experimental.1 Severity: important Starting from Linux-3.3 the psb_gfx kernel module was renamed to gma500_gfx. As result a kernel from debian experimental does not support KMS for GMA500/GMA600 videocards. Also KMS support for CIRRUS_QEMU is missing. Here is the corresponding lines from config-3.5-trunk-amd64 file # CONFIG_DRM_GMA500 is not set # CONFIG_DRM_GMA600 is not set # CONFIG_DRM_GMA3600 is not set # CONFIG_DRM_CIRRUS_QEMU is not set # CONFIG_STUB_POULSBO is not set -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643844: [bug 643844] lightdm: doesn't start at all
I fix the problem by copying file /etc/pam.d/gdm3-autologin from gdm3 package to /etc/pam.d/lightdm-autologin. Mikhail -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601708: smbnetfs: broken source code link in DPTS page
Actually, I have no idea how to implement this feature and I newer saw it on other packages. So I'll look to abiword and inkscape to get more information. If you know how it can be done, please let me know. Mikhail 2010/11/3 Prekates Alexandros apreka...@gmail.com: I sent that wish in good faith . Not with a complaint mentality. I noticed sth and i said why not? Packages like abiwird , or inkscape have a working git browse link. thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602033: smbnetfs.conf auth share wont work with winxp server
On Mon, 01 Nov 2010 00:11:04 +0200 Alexandros Prekates apreka...@gmail.com wrote: Package: smbnetfs Version: 0.5.2-1 Severity: normal the line auth pcwinxp/share alex alex wont work with winxp smb server. This is not a surprise, but rather misunderstanding of auth work principles. Usually, entering to //pcwinxp/share you'll need to enter //pcwinxp first. Thus you'll need a correct login/password to access pcwinxp server by itself. You are not specify this password in your auth file, so you'll faced with a problem. The auth lines like auth pcwinxp/share alex alex are usually required when you'll need to access network resources of pcwinxp with some default login/password pair, but //pcwinxp/share you'll need to access as some other user. Nevertheless, direct work with /mountpoint/pcwinxp/share (without trying to read the contents of /mountpoint/pcwinxp) should work. Thus commands like ls /mountpoint/pcwinxp/share, cp /mountpoint/pcwinxp/share/file ~/ and so on should work as expected. With the above line trying to connect with 'smbnetfs mountpoint' i'll get an error 'permission denied' after clicking the pcwinxp icon. But strangely to my the line: auth pcwinxp alex alex and auth workgroup/alex alex will work. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smbnetfs depends on: ii fuse-utils2.8.1-1.2 Filesystem in USErspace (utilities ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libfuse2 2.8.1-1.2 Filesystem in USErspace library ii libsmbclient 2:3.4.8~dfsg-1 shared library for communication w smbnetfs recommends no packages. smbnetfs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601708: smbnetfs: broken source code link in DPTS page
On Thu, 28 Oct 2010 21:10:52 +0300 Alexandros Prekates apreka...@gmail.com wrote: Package: smbnetfs Version: 0.5.2-1 Severity: wishlist In the Debian Package Tracking System page the source code link is broken. Hm... Could you give an example of packages that have such feature? A screenshot with red mark around a problematic place will be perfect. Mikhail -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages smbnetfs depends on: ii fuse-utils2.8.1-1.2 Filesystem in USErspace (utilities ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libfuse2 2.8.1-1.2 Filesystem in USErspace library ii libsmbclient 2:3.4.8~dfsg-1 shared library for communication w smbnetfs recommends no packages. smbnetfs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#466177: smbnetfs crashes
Hello Alexey, Can you tell me about your problem in more details. At first I'd like to get answer on the following question: 1) Do you use a Debian testing? 2) What samba version do you use? 3) Do you work from regular user account or from root user? 4) How familiar are you with strace and valgrind utilities? 5) Do you know what locale is? Do you know how to change it? (this help to avoid the russian error message) Then, I need to know your samba, libsmbclient and smbnetfs configuration 1) samba configuration (contents of the file /etc/samba/smb.conf). It's better to provide the output of testparm utility, because smb.conf contain to much trash 2) libsmbclient configuration (contents of the file ~/.smb/smb.conf from the user what run smbnetfs) 3) smbnetfs configuration (contents of the file ~/.smb/smbnetfs.conf from the user what run smbnetfs) Can you run smbnetfs in debug mode and repeat your test? There are 2 possibility 1) turn on smbnetfs log (set smbnetfs_debug level). Put the following line to your ~/.smb/smbnetfs.conf smbnetfs_debug 6 Possible values are from 0 to 10, but the value of 6 is usually enough. 2) Turn on samba log (set smb_debug level). Put the following line to your ~/.smb/smbnetfs.conf smb_debug number where the number is a value from 0 to 10 (no any recommendation, in hard situation i usually use 10) Sometime the reason of such behavior is the broken tdb database of your samba server. In this case it helps to delete all *.tdb files from /var/cache/samba and it's subdirectories, then restart samba and winbind (this is safe operation, this files will be recreated) Mikhail Kshevetskiy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466177: smbnetfs crashes
5) Do you know what locale is? Do you know how to change it? (this help to avoid the russian error message) Well, I tried to type # LC_ALL=en_US smbnetfs but this didn't help: errors were in russian Now I've dpkg-reconfigured locales packages and genetated english locale files. Well, be sure I can find out english messages. I won't post russian messages any more, excuse me. It's better use LANG=C, this locale is always present. Then, I need to know your samba, libsmbclient and smbnetfs configuration 1) samba configuration (contents of the file /etc/samba/smb.conf). It's better to provide the output of testparm utility, because smb.conf contain to much trash OK, here testparm output follows: [global] dos charset = cp866 unix charset = KOI8 workgroup = HACKERS server string = %h server security = SHARE obey pam restrictions = Yes passdb backend = tdbsam passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* . syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 os level = 50 preferred master = No local master = No domain master = No dns proxy = No wins server = 10.0.0.1 panic action = /usr/share/samba/panic-action %d invalid users = root That's Ok, I really need to get the following from this: -- domain configuration (you are not in domain) -- master browser settings (you are not a master browser) -- binding of interface (all interface) -- netbios name resolv order (lmhosts host wins bcast) 2) libsmbclient configuration (contents of the file ~/.smb/smb.conf from the user what run smbnetfs) This file does not exist That's bad, especially for russia. As result libsmbclient works in koi8-r. It's not suitable to feet all unicode characters to koi8-r. You are waiting for a problems. Put to your ~/.smb/smb.conf something similar to (this is usually sufficient for samba network without domain) [global] dos charset = cp866 display charset = utf-8 workgroup = HACKERS map to guest = Bad User deadtime = 5 # socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 create mask = 0640 directory mask = 0750 case sensitive = No wins server = 10.0.0.1 after that you should set samba_charset=utf-8 in your ~/.smb/smbnetfs.conf 3) smbnetfs configuration (contents of the file ~/.smb/smbnetfs.conf from the user what run smbnetfs) I've posted it in the very first message I miss it during the first reading. It's quite ok, just setup libsmbclient to utf-8 as i wrote above. Can you run smbnetfs in debug mode and repeat your test? There are 2 possibility 1) turn on smbnetfs log (set smbnetfs_debug level). Put the following line to your ~/.smb/smbnetfs.conf smbnetfs_debug 6 Possible values are from 0 to 10, but the value of 6 is usually enough. 2) Turn on samba log (set smb_debug level). Put the following line to your ~/.smb/smbnetfs.conf smb_debug number where the number is a value from 0 to 10 (no any recommendation, in hard situation i usually use 10) It make sense to use smb_debug=10 when you locate the place of error quite close. If there are no errors -- it's not help. Sometime the reason of such behavior is the broken tdb database of your samba server. In this case it helps to delete all *.tdb files from /var/cache/samba and it's subdirectories, then restart samba and winbind (this is safe operation, this files will be recreated) Could you tell me, how samba _server_ could cause _client_ crashes? I know an only scenario. libsmbclient search some information in samba server database (it created and managed by samba server). Sometime this database gets damaged by unknown reason. So when you start working with it you may face with null pointer call, infinite loops and so on. This will happen only on certain queries, so you will face a problem any time you connect to host that relate to broken record. It's most dangerous when the master browser record is damaged. In this case you will see an error on every network scanning Mikhail Kshevetskiy PS: it's possible to turn off network scanning through ~/.smb/smbnetfs.conf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466177: smbnetfs crashes
Hello Varun, Thank you for bug reporting. As i can see smbnetfs process die inside libsmbclient code during network scanning. This is the most typical problem with smbnetfs :((. Usually it is caused by 2 things: 1) masterbrowser with really bad settings (i know one or two people who was used to break his windows installation by unknown way with such result). Quite rare problem. 2) samba bug or problem with local samba configuration like https://bugzilla.samba.org/show_bug.cgi?id=5105 This is most common problem source. I try to communicate with Alexey to get more details. Mikhail Kshevetskiy On Sun, 17 Feb 2008 10:52:47 +0530 Varun Hiremath [EMAIL PROTECTED] wrote: Hi Alexey, On Sun, 17 Feb, 2008 at 05:37:42AM +0300, Alexey Bashtanov wrote: Package: smbnetfs Version: 0.3.10-2 Hello! Smbnetfs crashes and doesn't work Thanks for the report, but I can't reproduce this on my system. Could you please try the latest 0.3.11 version in sid and check if the problem persists? Hi Mikhail, Could you please have a look at this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466177 Looks to be some locale specific problem. Regards Varun -- Varun Hiremath Undergraduate Student, Aerospace Engineering Department, Indian Institute of Technology Madras, Chennai, India - Homepage: http://varun.travisbsd.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412284: unmount doesn't kill smbnetfs
Hello, the bug should be fixed in smbnetfs-0.3.9. See the fast_shutdown config file option for details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412284: unmount doesn't kill smbnetfs
This is rather feature. Here is the scenario: 1) libsmbclient remember the network configuration on start of SMBNetFS. You suspend your notebook and resume it in another network environment. So you get the network configuration mismatch. 2) fusermount -u umount filesystem and send the signal shutdown is required for SMBNetFS. Delivering of the signal may wait for finish of periodic network scan. Usually it's not a problem, as the scan do not require large time. In this case (the network configuration mismatch) the network scan may run for a much longer time. Mikhail Kshevetskiy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412284: unmount doesn't kill smbnetfs
Varun, this is rare and hard reproducible situation (this is a libsmbclient bug actually). To reproduce it you'll need to get the network configuration mismatch during the periodic network scan. The network scan takes about 15 seconds (depends on network size) and it occure once in a 5 min by default. Basing on this estimation the bug may appear in 5% of cases only. Mikhail Kshevetskiy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]