Bug#1030043: hplip-gui: traceback when launching hp-toolbox
Changing line 119 in /usr/share/hplip/base/password.py from: get_distro_std_name(os_name) to: get_distro_name() appears to fix the issue. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#1028643: downgrade to 2.13.1-4.2
Did you try Konomi's workaround instead of downgrading? That appears to fix it for me. On 1/21/23 03:23, Michal wrote: I can confirm that downgrade to package version 2.13.1-4.2 from stable fixes issues with font selection and color artifacts described above. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#1028643: fontconfig: 2.14.1-3 greatly changes font rendering
Yesterday I noticed a substantial change in the interface fonts for my whole system, I'm running Testing. They appear somewhat clearer, but don't align properly like the old fonts. I'm using MATE, and it caused things like titlebars to increase in size. I had noticed rendering changes with fontconfig in previous years, but this one seems to be a lot more than just rendering changes. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#1000697: linux-image-amd64: NTFS3 module missing in new kernels
Package: linux-image-amd64 Version: 5.15.3-1 Severity: wishlist Dear Maintainer, The Debian Linux kernels 5.15 and 5.16-rc1 do not have the newly introduced ntfs3 module, which was a fairly big new feature in 5.15. The module provides an in-kernel alternative to the ntfs-3g package. To add the module, add "CONFIG_NTFS3_FS=m" to the kernel config. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-amd64 depends on: ii linux-image-5.15.0-1-amd64 5.15.3-1 linux-image-amd64 recommends no packages. linux-image-amd64 suggests no packages. -- no debconf information
Bug#994538: dh-python: alias /usr/bin/python disappears after installation
This appears to be the same as #991009, upgrading dh-python breaks python-is-python2, causing the /usr/bin/python symlink to disappear upon uninstallation. I currently have dh-python held at the old version, because I still have some python2 packages that I need to figure out what to do about. To fix this issue, maybe he could just install the python-is-python3 package, or have dh-python recommend/depend on it. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
Upstream made a couple of commits which fix the Jack issue for me: https://gitlab.gnome.org/GNOME/glibmm/-/commit/b67b77cb8cd37a7ec33ad15702831ab45ced7f64 https://gitlab.gnome.org/GNOME/glibmm/-/commit/f8b8e70fee19487df19019b4f8810715a7c77ad0 nos...@kota.moe also made some test code that triggers the bug, the bug goes away after commits. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
I posted this to the upstream bug report: --- After debugging glib for a while, I might've found the issue. According to the documentation of g_quark_from_static_string(), that function shouldn't be used to initialize a global variable, but that's how it's being used in the crash location in glibmm. As part of doing symbol checks, Jack loads and unloads the firewire module a number of times, that has the glibmm dependency. Then it loads the module normally. Glibmm initializes each load, it shows the glib functions being called each time. Since the glibmm initialization uses the static_string function, glib stores the pointer to the static string inside it's hash table and creates a new gquark (the doc says a gquark object creation at this stage is too early). What should be happening, is that due to the module unloads, previously stored string references become invalid in the hash table, causing a segfault when doing an strcmp, the function doc says to not use that function if you're going to unload the module. The hash table's address itself remains the same during all of the loads and unloads, showing that it's not being unloaded. The g_quark_from_string() function works, because it creates copies of the strings instead, so it's unload-safe. Unlike what we thought of before, the string that glibmm passes to the glib function remains valid all the way to the crash, the culprit is that strcmp compares against a pointer to invalid memory that comes from the glib hash table. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
I found that my edits were affecting the wrong file (I was working on a cached file instead, there were multiple copies of the code), and so my string modification doesn't actually work, it results in the same segfault. Changing the function to q_quark_from_string() works. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
On 10/3/21 6:33 AM, Simon McVittie wrote: On Sat, 02 Oct 2021 at 20:48:55 +1000, 小太 wrote: Perhaps jack_firewire.so and/or glibmm should be linked with -Wl,-z,nodelete to prevent it from being removed from the address space even after dlclose()? That would ensure that its static strings remain in memory. I think my code only showed a dlopen() with a single call, but my backtrace shows that it attempts to load the library twice (with caught exceptions), followed by a possible success the third time, then the glibmm init and segfault. I don't know why the library load is failing. Since I did a stack allocation instead, I'd think that memory would become invalid if the library unloaded before the glibmm init. I'd mainly have to play with it in gdb more to see what's happening. nos...@kota.moe might've done more debugging than I did. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
On 10/3/21 4:59 AM, 小太 wrote: On Sun, 3 Oct 2021 at 20:47, Ryan Thoryk wrote: "Bad permissions for mapped region at address" can also mean it tried to read from unreadable memory. The memory was mapped at some point in the past, so it doesn't say unallocated memory Also consider the segfault comes from strcmp(). Why would strcmp() ever need to write to memory? You can verify with a disassember the segfault comes from a read The strcmp stumped me too. I assumed it was trying to copy from a null pointer, but valgrind shows that the address wasn't null. I forgot about the strcmp detail when writing my comment, strcmp is read-only. I suspect this "worked" to fix the issue only due to a memory layout change, and luck would have it that after your rebuild it now tries to read from readable memory (albeit still not the expected memory) After looking over the glib docs, the function does a const on the string, so it shouldn't be able to do a write. I don't know enough about handling C-strings (I've mostly done C++ strings), but the only difference is the location of stored memory, maybe it's getting an access error when trying to access the literal (since it's being done from an external library), as opposed to a stack allocation. That's the only thing I can think of. Valgrind doesn't show any warning or error using this method, so it appears to be fine. I'll bring this up on the glibmm upstream and see what they say. I think the proper way to to define it is "static const char[]" instead of "char[]", but it might not matter that much. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
I also reported my solution comment to your upstream ticket. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
When I had jack dump out it's module filenames during library load, it
only appeared to load jack_firewire once. The clue as to what's
happening is that valgrind reports "Bad permissions for mapped region",
if you look at the function, it's trying to pass a string literal, the
valgrind error means that it's trying to modify the string, and since
it's read-only, it results in a segfault. The string and address are valid.
The appropriate fix appears to be to either use your alternative
function, or to create a C string and pass it to the function:
---
char binding[] = "glibmm__Glib::Binding::manage");
GQuark quark_manage = g_quark_from_static_string(binding);
---
or
---
GQuark quark_manage = g_quark_from_string("glibmm__Glib::Binding::manage");
---
Both of those changes work on my system, and jack_firewire now works for
me again. One thing online says about that function, "This function
must not be used before library constructors have finished running."
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
Bug#995271: nvidia-kernel-dkms: does not install with linux-image-5.14-amd64
For those getting build errors, this is due to the related 5.14 build patch not being part of the Testing package (patch level 2), it was added in patch level 3 which was in Sid/Unstable but apparently never migrated to Testing. I've been having the same issue too. It appears that a new Nvidia driver version is in Sid (470.63.01), so eventually when that migrates down, it should fix this issue. Hopefully that speeds up because systems with Nvidia graphics are unable to run the newer 5.14 kernel at the moment, and have to stick with 5.10. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
After installing a debug version of glibmm, I've attached the related backtrace showing the glibmm code lines. The "binding.cc" is the glib/glibmm/binding.cc file. The old (working) version doesn't appear to use the related g_quark_from_static_string() function that crashes. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 #1 0x7f0771e943b9 in g_str_equal () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f0771e92e03 in g_hash_table_lookup () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f0771eb5c8a in g_quark_from_static_string () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f0771e0ead0 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at binding.cc:32 #5 _GLOBAL__sub_I_binding.cc(void) () at binding.cc:370 #6 0x7f0773b0610e in call_init (l=, argc=argc@entry=3, argv=argv@entry=0x7ffdbb8e0208, env=env@entry=0x7ffdbb8e0228) at dl-init.c:74
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
I tried force-downgrading the libglibmm package to the Debian Bullseye version (2.66 back to 2.64), the crash goes away, and my audio hardware works again with Jack. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages
I wanted to chime in on this bug, since I'm getting basically the same issue. I'm running Debian Testing. My situation is a little different, because I'm using an M-Audio firewire device with Jack2 on a VIA VT6315 card, and so I need the firewire module. I recently swapped out the firewire card but couldn't get the audio device to work, since Jack kept segfaulting on startup. Tonight I booted a Debian 11 live cd, and the device and Jack work flawlessly on it. The device has trouble working with ALSA, so I use the FFADO system instead. This is what it looks like when running: ryan@andromeda:~$ jackd -d firewire jackdmp 1.9.19 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2016 Grame. Copyright 2016-2021 Filipe Coelho. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details no message buffer overruns no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 self-connect-mode is "Don't restrict self connect requests" Segmentation fault (core dumped) I downloaded the Jack source code and did some GDB debugging, and found that it's segfaulting when doing a dlopen() on the jack_firewire.so module. Jack appears to run fine with the ALSA module instead, but not firewire. I attached the backtrace from GDB. I had been going over my system's linker configuration to see if there was something wrong, and then I found this bug report. Since glib is crashing during a string comparison, the culprit appears to be the glibmm frontend's constructor. I didn't set up an environment to debug glibmm yet, but let me know if there's something you'd like me to try out. I was wanting to find out details on that string comparison. You might be able to reproduce it if you try to use the firewire device module like I did. This is the output when running Valgrind on Jack: ==8689== ==8689== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==8689== Bad permissions for mapped region at address 0x6594034 ==8689==at 0x4D09370: __strcmp_sse2_unaligned (strcmp-sse2-unaligned.S:24) ==8689==by 0x6800F58: g_str_equal (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0) ==8689==by 0x67FF9E1: g_hash_table_lookup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0) ==8689==by 0x6822C99: g_quark_from_static_string (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0) ==8689==by 0x6938BAF: ??? (in /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1.3.0) ==8689==by 0x401010D: call_init.part.0 (dl-init.c:74) ==8689==by 0x40101EF: call_init (dl-init.c:37) ==8689==by 0x40101EF: _dl_init (dl-init.c:121) ==8689==by 0x4DAAB6C: _dl_catch_exception (dl-error-skeleton.c:182) ==8689==by 0x4014483: dl_open_worker (dl-open.c:783) ==8689==by 0x4DAAB0F: _dl_catch_exception (dl-error-skeleton.c:208) ==8689==by 0x4013D09: _dl_open (dl-open.c:864) ==8689==by 0x5025257: dlopen_doit (dlopen.c:66) -- Ryan Thoryk r...@thoryk.com r...@tliquest.net #0 __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31 #1 0x7f7abc466f59 in g_str_equal () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f7abc4659e2 in g_hash_table_lookup () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f7abc488c9a in g_quark_from_static_string () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f7abc3dbbb0 in () at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #5 0x7f7abe0df10e in call_init (l=, argc=argc@entry=3, argv=argv@entry=0x7ffca09e2288, env=env@entry=0x7ffca09e22a8) at dl-init.c:74 #6 0x7f7abe0df1f0 in call_init (env=0x7ffca09e22a8, argv=0x7ffca09e2288, argc=3, l=) at dl-init.c:37 #7 _dl_init (main_map=0x55dd66345d90, argc=3, argv=0x7ffca09e2288, env=0x7ffca09e22a8) at dl-init.c:121 #8 0x7f7abdc19b6d in __GI__dl_catch_exception (exception=exception@entry=0x0, operate=operate@entry=0x7f7abe0e2a00 , args=args@entry=0x7ffca09e1800) at dl-error-skeleton.c:182 #9 0x7f7abe0e3484 in dl_open_worker (a=a@entry=0x7ffca09e19a0) at dl-open.c:783 #10 0x7f7abdc19b10 in __GI__dl_catch_exception (exception=exception@entry=0x7ffca09e1980, operate=operate@entry=0x7f7abe0e30e0 , args=args@entry=0x7ffca09e19a0) at dl-error-skeleton.c:208 #11 0x7f7abe0e2d0a in _dl_open (file=0x7ffca09e1980 "", mode=-2147483390, caller_dlopen=0x7f7abe038bee , nsid=-2, argc=3, argv=0x7ffca09e2288, env=0x7ffca09e22a8) at dl-open.c:864 #12 0x7f7abd8ef258 in dlopen_doit (a=a@entry=0x7ffca09e1bd0) at dlopen.c:66 #13 0x7f7abdc19b10 in __GI__dl_catch_exception (exception=exception@entry=0x7ffca09e1b70, operate=operate@entry=0x7f7abd8ef200 , args=args@entry=0x7ffca09e1bd0) at dl-error-skeleton.c:208 #14 0x7f7abdc19bcf in __GI__dl_catch_error (objname=objname@
Bug#986709: Rsnapshot removal
Upon upgrading my backup server tonight, I found that rsnapshot was removed from Debian Bullseye. In my opinion, this shouldn't have happened. I currently use it for backups on my main production server, and even in my previous Linux admin job, I had implemented it for company systems. There is no practical alternative to it, it's just a wrapper around rsync, nothing else works like that as far as I know. I also noticed that a newer version is in sid, couldn't that have been migrated to testing and released? I've been using it since 2014 (daily) as far as I know. I could look for alternatives, but it works too well in my opinion. To add what I think is a very good point for this, I recently opened a bug report for a package called statsvn, which didn't even work in both stable and testing, apparently nobody even verified that it worked before releasing it in Buster, it would fail with a java version check. Rsnapshot, a fine working package, was removed, but a perpetually broken package wasn't. Statsvn hasn't been released upstream for apparently 11 years. For now, I might see if I can use the sid version on stable. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 10:09 AM, Ryan Thoryk wrote: On 7/17/21 9:44 AM, Steve McIntyre wrote: I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. One thing to add to that - when I did a "grub-install" on the newer AMI, it didn't write a "EFI/debian" folder, just an "EFI/BOOT" folder, which means that it might be working properly. If that's the case, then the older instances are broken, which would affect existing systems. I'm not sure if a grub upgrade would change that or not. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 9:44 AM, Steve McIntyre wrote: Hi Ryan, So when you say "spin up a new Debian ARM VM on AWS", what exact image are you using here? It sounds like the build process for that image needs to be fixed to DTRT for the platform. Then you and other users won't be bitten by this problem... I found that I was using an older ARM image from last year, but that doesn't mean the issue was fixed later. In AWS's community AMI section, the main one I tried is listed as "debian-10-arm64-20200511-260". When you launch it, if you do a package upgrade it installs a newer version of grub. Then running a grub-install makes it unbootable. If you do the dpkg-reconfigure method, you have to choose "yes" to the "force extra installation" question, if you choose "no", it won't boot anymore. I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", and that one reboots fine if you do a "grub-install", but that's because it didn't install a newer version of grub, since the packages are recent. I don't know what would happen if it installed a newer grub, you might have to look into that. In the boot folder the EFI boot loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no "EFI/debian" folder. I'm not sure what they did to generate the AMI image. The AMI IDs I used are: ami-00249fe66e0872181 and ami-025a7500c83d92798 I didn't try the Marketplace one. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On 7/17/21 8:18 AM, Steve McIntyre wrote: On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote: EFI/debian is *NOT* wrong, it's the correct location for a system that has working firmware which supports setting UEFI boot variables. If you *also* need to write a copy of grub (etc.) to the removable media location (EFI/boot) then that's supported as well by the Debian packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the system asks about that. Thanks for that suggestion, that explains the correct procedure in resolving the issue. What I'm trying to point out though (I tried this), is that if you spin up a new Debian ARM VM on AWS, and run "grub-install" *without* doing a dpkg-reconfigure, it results in an unbootable system. To recover the system, you have to attach the disk on a different VM and replace the old boot loader image with the new one, then it boots again. After running the dpkg-reconfigure command though like you suggested, it copied over the EFI boot image to the "BOOT" folder, and also set the nvram variables to apparently boot from the "debian" folder, so that solved the problem for me. After doing that, the system comes up after a reboot with the newer grub modules. With others on here, the issue might have to do with the system executing an older EFI boot image resulting in a module mismatch, like what happened to me. Your dpkg-reconfigure suggestion might fix their issues too. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson wrote: In general, this means that grub-install is not installing to the place that your firmware is actually booting from, which causes the core image (installed to a file under /boot/efi/ on UEFI systems) to be out of sync with the modules (installed to a subdirectory of /boot/grub/). This is much rarer on UEFI systems than on BIOS systems, but it's still possible in some misconfigured cases. Could you please attach the output of "sudo grub-install --debug", "sudo efibootmgr -v", and "sudo find /boot/efi -ls"? Thanks for looking into this issue. I did some investigating this morning for my situation, and found the problem. Your suggestion is what helped me. The test case I had was that if you start a new Debian ARM VM on AWS, and run grub-install on it, future boots fail, where they stop at the rescue prompt and an "insmod normal" shows the error message. In other words, "grub-install" was breaking grub, which is pretty bad. After some investigating I found that grub-install was writing the EFI boot loader image (grubaa64.efi) to the wrong location on the system. It should be installing into /boot/efi/EFI/BOOT but is putting it into /boot/efi/EFI/debian. Future boots fail because the loader image that executes (the one in BOOT) is the older version and is out of sync with the modules. I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, wondering if it would try to use the "EFI/debian" one, and after rebooting the system was stuck in an EFI shell (couldn't find a boot loader), so the "EFI/debian" folder is clearly wrong. This could be similar to what's happening with others on here. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#990488: statsvn: Package in stable does not work
Package: statsvn Version: 0.7.0.dfsg-9 Severity: grave Justification: renders package unusable Dear Maintainer, When trying to use the statsvn utility, this fatal error message is encountered: SEVERE: Subversion binary is incorrect version. Found: 1.10.4, required: 1.3.0 This makes the utility broken on both stable and testing. It appears that FreeBSD has a patch for this, that disables the version check: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229325 -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages statsvn depends on: ii default-jre [java-runtime] 2:1.11-71 ii java-wrappers 0.3 ii libsvnkit-java 1.8.14-3 ii openjdk-11-jre [java-runtime] 11.0.11+9-1~deb10u1 ii statcvs1:0.7.0.dfsg-7 ii subversion 1.10.4-1+deb10u2 statsvn recommends no packages. statsvn suggests no packages. -- no debconf information
Bug#984760: grub-pc: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
I have something to add to this. This morning I was writing up a document on how to convert an existing Debian amd64 AWS VM to arm64 without reinstalling, which is something I was interested in doing in the future to a fairly complex system install that I wasn't excited about trying to reinstall/migrate. Everything worked with the conversion, except for the grub stage, grub failed to start on the ARM instance and was stuck at the grub-rescue prompt. When typing "insmod normal", it shows the "symbol `grub_is_lockdown` not found" error. I managed to get it working by copying grub modules from an existing Debian ARM VM over to it, I did that because I noticed that the modules were of a newer version and a different size. I'm not sure if the "grub-install" step was needed, but after investigating I found that when I ran grub-install a standard Debian-provided ARM AWS community instance and rebooted, the instance fails to boot in the same way. This is my document if you were interested, I mention the error in it: https://ryan.thoryk.com/linux/arm_convert.html -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#971694: linux-image-5.7.0-0.bpo.2-amd64: Front audio ports do not work on Gigabyte X570 GAMING X motherboard
I have a desktop system with probably the same issue, and it also has a Gigabyte board (older one though). With mine, the issue had something to do with the automatic port detection, and at one point I was able to get it working by plugging speakers into the rear port and then plugging in headphones afterwards. I just tried that now, and it doesn't seem to work that way anymore, so I'm not sure. Try that and then choose "headphones" for the output and see if it does anything. On Mon, 5 Oct 2020 21:46:29 +1300 Aidan Gauland wrote: > Package: src:linux > Version: 5.7.10-1~bpo10+1 > Severity: normal > > Dear Maintainer, > > I just finished setting up my desktop with a Gigabyte X570 GAMING X > motherboard > and the rear audio ports work fine, but I cannot get audio out of the front > headphone jack or use a microphone with the front microphong jack. In > pavucontrol, I can explicitly set the output and input ports to the front > ports, but that does not make them work. I have also tried stopping > pulseaudio > to see whether they would work just bare ALSA, but that made no difference. > > Regards, > Aidan Gauland -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#971000: Acknowledgement (linux-image-5.8.0-2-amd64: Periodic networking failure with recent kernels in Testing)
This issue happened again on my system, and I was able to confirm that the system (and networking) recovers fine after unplugging the Netgear WNA3100M USB WIFI adapter. That adapter uses the rtl8192cu driver. I was connecting the system using the on-board ethernet and not that wifi adapter (the wifi was left unassociated). I'll leave it unplugged and see if the system works fine now. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types
Yes, it was just the Marketplace that I was trying to get the AMI from. Thanks for your help. On 10/1/20 6:39 PM, Noah Meyerhans wrote: > I've confirmed that the Marketplace UI still doesn't let us enable t4g.* > and opened a support request with AWS to see if they can enable this for > us. > > For now, use the AMIs listed at > https://wiki.debian.org/Cloud/AmazonEC2Image/Buster > -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#971561: cloud.debian.org: ARM-based Buster AMIs don't support new T4g instance types
Package: cloud.debian.org Severity: wishlist Dear Maintainer, I've been wanting to run Debian on Amazon's new T4g instances, which utilize the ARM-based Graviton2 processor. The current AMI's don't appear to support this, and I assumed it would be fixed as part of the 10.6 update, which it wasn't. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#971000: linux-image-5.8.0-2-amd64: Periodic networking failure with recent kernels in Testing
Package: src:linux Version: 5.8.10-1 Severity: important Dear Maintainer, I've been experiencing periodic random network controller failures on recent kernels in Testing. This started happening possibly around the 5.6 kernel release, and wasn't happening sometime before that. The system is mainly using wired ethernet on an Atheros onboard controller, and also has an unused NetGear WNA3100M USB WIFI controller. After running the system for some time (the length of which has been random so far), the wired ethernet controller stops working and also apparently the WIFI controller (haven't verified the WIFI failure though). Since I log into the system remotely quite frequently, SSH sessions become unresponsive and require a reboot to get it working again. Most everything else on the system appears to work fine while the issue is happening. I was thinking of taking out the NetGear adapter to see if that's possibly causing the issue somehow, but I haven't had any known way to trigger the problem to reproduce it, besides waiting. In the kernel command line, I have the Intel IOMMU switched off to fix a past issue with a firewire controller card; I don't know if this would be related. I'm not sure if this issue is a hardware fault or some kernel bug. This mainly started happening a few months or so ago, and I assumed it would've been eventually fixed, but it's still an issue. Here's some of the messages from when the issue started. The error "swiotlb buffer is full" shows up for both the USB controller (possibly for the Wifi adapter) and also the Atheros LAN. These messages are the beginning of the issue, most of the messages afterwards are basically the same: - Sep 25 21:23:24 andromeda kernel: [50194.575217] rtl8192cu: Tx queue select: 0x05 Sep 25 21:24:46 andromeda kernel: [50276.501148] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501209] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501268] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501327] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501386] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501445] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501504] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501563] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501622] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.501683] ehci-pci :00:1a.0: swiotlb buffer is full (sz: 1 bytes), total 32768 (slots), used 32768 (slots) Sep 25 21:24:46 andromeda kernel: [50276.508873] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.508931] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.508990] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509049] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509109] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509110] usb 1-1-port5: Cannot enable. Maybe the USB cable is bad? Sep 25 21:24:46 andromeda kernel: [50276.509169] usb 1-1-port5: cannot disable (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509228] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509288] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509347] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509407] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509466] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509467] usb 1-1-port5: Cannot enable. Maybe the USB cable is bad? Sep 25 21:24:46 andromeda kernel: [50276.509526] usb 1-1-port5: cannot disable (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509585] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509645] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509704] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46 andromeda kernel: [50276.509764] usb 1-1-port5: cannot reset (err = -11) Sep 25 21:24:46
Bug#961981: linux-image-5.6.0-2-amd64: BUG: Bad page state in process alsa-sink-ALC89 pfn:816801
I actually had a similar crash on my system, and it apparently was due to bad RAM modules which I've now taken out. I'll be trying to stress-test the system to see if it's stable now. Test yours first with something like memtest86+. I was able to identify 2 separate bad memory modules with that, which was surprising to me. The Debian version of memtest86+ didn't work for me (froze during run) so I had to download from the www.memtest.org website and that one worked. My system had a kernel panic during a null pointer dereference in relation to a bad page. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#961834: clearlooks-phenix-theme: Theme look distorted possibly due to recent GTK3 upgrade
Package: clearlooks-phenix-theme Version: 7.0.1-3 Severity: important Dear Maintainer, I've been running Testing on my desktop computer, and recently I had upgraded a number of packages including the GTK3 libraries, and the overall look of certain GTK3 themes including clearlooks-phenix has broken. I'm using the MATE desktop environment, so at the moment I'm not sure if the issue has to do with the themes themselves, GTK3, or MATE (I might do more testing with this issue and report further). The problem is that there seems to be more sizer bars and boxes around the windows, especially right under the title bar, affecting the appearance of the windows. Before this issue, if I remember correctly, this theme eventually had more sizer boxes appear around certain areas, and those sizer boxes aren't visible in many other themes (an example comparison theme is Bluebird, which appears fine to me). -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_BAD_PAGE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages clearlooks-phenix-theme depends on: ii libgtk-3-0 3.24.20-1 Versions of packages clearlooks-phenix-theme recommends: ii gtk2-engines 1:2.20.2-5 clearlooks-phenix-theme suggests no packages. -- no debconf information
Bug#888465: CPU usage reporting issues
(cleaned the post up for readability, sorry about that) On 01/25/2018 05:40 PM, Hans van Kranenburg wrote: This means that your vcpus want to execute work but are not being scheduled on a physical cpu core. Either the physical machine gets too much work from all the virtual machines that are requesting cpu time, or other things are going on, like your virtual machine getting paused (e.g. when doing live migration there's a handover moment when it's shortly paused and then resumed, this is also visible as a short 100% steal spike). After going over log files, it appears that the issue started when Amazon did a live migration of the VM, probably for the Meltdown patching. A patch to fix that cpu accounting breakage (picked from linux 4.15) was included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?) you could be seeing that one happening. The versions were both 4.9.30-2+deb9u2 and the latest, 4.9.65-3+deb9u2. So basically the kernel never recovered properly after being paused during a live migration. Because of the mentioned steal time fix that was included in a version in between the 2 versions you mention, my first suggestion would be to see if the symptoms on the old and new kernel are exactly the same, or if they are only similar but different. Hans I already rebooted the system running the 4.9.65 kernel, and beforehand, the symptoms were the same. The CPU usage stats went back to normal after the reboot. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#888465: CPU usage reporting issues
On 01/25/2018 05:40 PM, Hans van Kranenburg wrote: Hi Ryan, On 01/26/2018 12:20 AM, Ryan Thoryk wrote: Package: linux-image-4.9.0-5-amd64 Version: 4.9.65-3+deb9u2 Severity: normal I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3 and 4.9.0-5. The machines are running on Amazon EC2, which could be related. With the "sar" utility, after some time, the system's "steal" value periodically is 100%, This means that your vcpus want to execute work but are not being scheduled on a physical cpu core. Either the physical machine gets too much work from all the virtual machines that are requesting cpu time, or other things are going on, like your virtual machine getting paused (e.g. when doing live migration there's a handover moment when it's shortly paused and then resumed, this is also visible as a short 100% steal spike). After going over log files, it appears that the issue started when Amazon did a live migration of the VM, probably for the Meltdown patching. and the normal CPU user/system values, including idle, are always 0. When running a cpu-intensive app and using the "top" utility, the user and system values are always 0, the "idle" field stays at 100%, and only the "wait" field increases. Sounds a lot like this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871608 A patch to fix that cpu accounting breakage (picked from linux 4.15) was included in 4.9.65-3. So only for the 4.9.0-3 (which actual version?) you could be seeing that one happening. The versions were both 4.9.30-2+deb9u2 and the latest, 4.9.65-3+deb9u2. So basically the kernel never recovered properly after being paused during a live migration. The attached file shows the "sar" output around the time the issue started. This has happened on 2 separate machines (started at different times on each), and a reboot appears to (temporarily) fix the issue. I'm wondering if anyone else has this issue, and if it could be something to do with the hypervisor. Because of the mentioned steal time fix that was included in a version in between the 2 versions you mention, my first suggestion would be to see if the symptoms on the old and new kernel are exactly the same, or if they are only similar but different. Hans I already rebooted the system running the 4.9.65 kernel, and beforehand, the symptoms were the same. The CPU usage stats went back to normal after the reboot. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#888465: Additional example
Here's an additional example, showing the "vmstat" command output while running a cpu-intensive program. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net ryan@elaina:~$ vmstat 2 procs ---memory-- ---swap-- -io -system-- --cpu- r b swpd free buff cache si sobibo in cs us sy id wa st 1 0 1213872 544528 0 123229200 7 300 0 0 4 0 96 1 0 1213872 544188 0 123228800 2 3 393 264 0 0 0 0 0 1 0 1213872 544176 0 123229200 2 2 395 238 0 0 0 0 0 1 0 1213872 544368 0 123229200 0 0 511 365 0 0 0 0 0 1 0 1213872 544568 0 123229200 084 388 234 0 0 0 0 100 1 0 1213872 544284 0 123230000 6 0 541 426 0 0 0 0 0 1 0 1213872 544132 0 123230400 0 0 433 337 0 0 0 0 0 1 0 1213872 544140 0 123229200 0 2 356 193 0 0 0 0 0 1 0 1213872 544040 0 123231200 820 455 410 0 0 0 0 0 1 0 1213872 543916 0 123231600 0 230 386 260 0 0 0 0 0 1 0 1213872 544288 0 123231600 0 0 354 226 0 0 0 0 0 1 0 1213872 545684 0 123231600 073 385 272 0 0 0 0 0 1 0 1213872 545808 0 123231600 010 589 473 0 0 0 0 0 1 0 1213864 545652 0 123232040 4 126 763 656 0 0 0 0 0 1 0 1213864 545528 0 123232000 0 232 417 267 0 0 0 0 0
Bug#888465: CPU usage reporting issues
Package: linux-image-4.9.0-5-amd64 Version: 4.9.65-3+deb9u2 Severity: normal Hi, I'm having an issue with CPU usage reporting, tested on kernels 4.9.0-3 and 4.9.0-5. The machines are running on Amazon EC2, which could be related. With the "sar" utility, after some time, the system's "steal" value periodically is 100%, and the normal CPU user/system values, including idle, are always 0. When running a cpu-intensive app and using the "top" utility, the user and system values are always 0, the "idle" field stays at 100%, and only the "wait" field increases. The attached file shows the "sar" output around the time the issue started. This has happened on 2 separate machines (started at different times on each), and a reboot appears to (temporarily) fix the issue. I'm wondering if anyone else has this issue, and if it could be something to do with the hypervisor. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net 11:05:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 11:15:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 11:25:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 11:35:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 11:45:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 11:55:01 AM all 0.01 0.00 0.02 0.00 0.00 99.97 12:05:01 PM all 0.01 0.00 0.01 0.00 0.00 99.97 12:15:01 PM all 0.01 0.00 0.01 0.00 0.00 99.97 12:25:01 PM all 0.01 0.00 0.02 0.00 0.00 99.97 12:25:01 PM CPU %user %nice %system %iowait%steal %idle 12:35:01 PM all 0.01 0.00 0.02 0.00 0.00 99.97 12:45:01 PM all 0.01 0.00 0.02 0.00 0.00 99.97 12:55:01 PM all 0.02 0.00 0.02 0.00 0.00 99.96 01:05:01 PM all 0.01 0.00 0.02 0.00 0.00 99.97 01:15:01 PM all 0.00 0.00 0.00 0.00100.00 0.00 01:25:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 01:35:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 01:45:01 PM all 0.00 0.00 0.00 0.00100.00 0.00 01:55:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 02:05:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 02:15:01 PM all 0.00 0.00 0.00 0.00100.00 0.00 02:25:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 02:35:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00 02:45:01 PM all 0.00 0.00 0.00 0.00100.00 0.00 02:55:01 PM all 0.00 0.00 0.00 0.00 0.00 0.00
Bug#885623: Acpitool can't handle more than 2 batteries (with patch)
Package: acpitool
Version: 0.5.1-4+b4
Severity: important
Tags: patch
I've been having an issue with acpitool's battery reporting on my laptop. I'm
using a ThinkPad T460, which has 2 batteries, and I have a USB wireless mouse
that reports as a third battery. I found that acpitool can't handle reporting
more than 2 batteries, resulting in this output:
---
ryan@t460:~$ acpitool -B
Battery #1 : slot empty
Battery #2 : slot empty
Invalid battery number, fix this
Battery #3 : slot empty
---
I've attached a patch which fixes this issue, by correcting some bad code.
Output from the patched version:
---
ryan@t460:~$ acpitool -B
Battery #1 : present
Remaining capacity : 22620 mWh, 99.78%
Design capacity: 23480 mWh
Last full capacity : 22670 mWh, 96.55% of design capacity
Capacity loss : 3.450%
Present rate : 0 mW
Charging state : Unknown
Battery type : Li-ion
Model number : 45N1113
Serial number : 4292
Battery #2 : present
Remaining capacity : 22810 mWh, 96.65%, 00:22:49
Design capacity: 23200 mWh
Last full capacity : 23600 mWh
Present rate : 2077 mW
Charging state : Charging
Battery type : Li-ion
Model number : 45N1775
Serial number : 7141
Battery #3 : slot empty
---
--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net
--- acpitool-0.5.1/src/battery.cpp 2017-12-28 10:59:11.257699374 -0600
+++ acpitool-0.5.1.new/src/battery.cpp 2017-12-28 11:03:21.373492694 -0600
@@ -413,19 +413,8 @@
closedir(battery_dir);
//we found all dir entries, now process them //
-switch(bat_nr) // select battery first //
-{
- case 1 : if(bat_count==1)
- start = 0;
- if(bat_count==2)
- start = 2;
- break;
- case 2 : start = 0;
- break;
- default : cout<<"Invalid battery number, fix this"<<endl;
- return -1;
- break;
-} //NOTE : scandir returns entries in reverse order //
+start = bat_count - bat_nr;
+//NOTE : scandir returns entries in reverse order //
// first get battery presence from 1st file//
@@ -608,19 +597,8 @@
/* let's see if this messy indexing with files actually gives us the right files and numbers */
//we found all dir entries, now process them //
-switch(bat_nr) // select battery first //
-{
- case 1 : if(bat_count==1)
- start = 0;
- if(bat_count==2)
- start = 1;
- break;
- case 2 : start = 0;
- break;
- default : cout<<"Invalid battery number, fix this"<<endl;
- return -1;
- break;
-} //NOTE : scandir returns entries in reverse order //
+start = bat_count - bat_nr;
+//NOTE : scandir returns entries in reverse order //
// printf("From Get_Bat_Info, start= %d. \n ", start); //
Bug#884569: Unknown Symbol error when loading Tun driver
Package: linux-image-4.9.0-4-amd64 Version: 4.9.51-1 Severity: important I've been trying to use the vpn on my system, but am getting the error "Unknown symbol dev_get_valid_name (err 0)" when trying to load the "tun" driver. When using modprobe, I get: "modprobe: ERROR: could not insert 'tun': Unknown symbol in module, or unknown parameter (see dmesg)" I haven't tried any other kernels to see if they're affected. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#868718: Acknowledgement (qemu: Qemu fails to run on Stretch, due to missing libraries)
I found that rebuilding the packages from source fixes the problem. -- Ryan Thoryk r...@thoryk.com r...@tliquest.net
Bug#868718: qemu: Qemu fails to run on Stretch, due to missing libraries
Package: qemu Version: 1:2.8+dfsg-6 Severity: important Dear Maintainer, Qemu is not running on my Stretch machine, due to missing libraries. I'm going to build from source and see if that fixes it. ryan@t420:~$ qemu-system-i386 qemu-system-i386: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory ryan@t420:~$ ldd /usr/bin/qemu-system-i386 --snip-- libnss3.so.1d => not found libnssutil3.so.1d => not found libsmime3.so.1d => not found libssl3.so.1d => not found libplds4.so.0d => not found libplc4.so.0d => not found libnspr4.so.0d => not found --snip-- -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu depends on: ii qemu-system 1:2.8+dfsg-6 ii qemu-user1:2.8+dfsg-6 ii qemu-utils 1:2.8+dfsg-6 qemu recommends no packages. Versions of packages qemu suggests: pn qemu-user-static -- no debconf information
Bug#462958: Some more information
We recently tried upgrading libpam-ldap on one of our mail servers here, which triggered this bug (caused saslauthd to segfault on every authentication attempt). We originally tried a number of things to resolve the issue since we didn't exactly know what was causing it, but then found that rolling back libpam-ldap fixed it. Some interesting things that I noticed were that the local PAM authentication via LDAP never broke during this; we were still able to log into multiple accounts on the machine with the newer libpam-ldap, and also Dovecot authentication via PAM was working fine - the only thing that broke was saslauthd. I'm thinking that the bug really could be in saslauthd and not libpam_ldap, and might possibly be an old workaround in sasl's code that broke with an API or behavior change in the newer libpam_ldap. -- Ryan Thoryk System Administrator onShore Networks, LLC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507577: xosview: dpatch for additional mem fields
Hmm - that's strange. Are you using 1.8.3+debian-11? (that's what it
was diffed against). It applies cleanly for me, and when added to
debian/patches/00list it patches and builds fine with dpkg-buildpackage.
---
cat debian/patches/24_enhanced_mem.dpatch | patch -p1
patching file linux/memmeter.cc
patching file Xdefaults
patching file Xdefaults.in
patching file Xdefaults.stipple
---
I'll attach the full patch I use for my own builds (has my changelog
entry, addition to 00list and the patch itself).
Kartik Mistry wrote:
I am not able to apply your patch cleanly. Can you look at it and
patch against latest version in Debian?
Thanks.
diff -urN xosview-1.8.3+debian.old/debian/changelog xosview-1.8.3+debian/debian/changelog
--- xosview-1.8.3+debian.old/debian/changelog 2008-11-26 13:14:53.0 -0600
+++ xosview-1.8.3+debian/debian/changelog 2008-11-26 13:13:30.052495000 -0600
@@ -1,3 +1,10 @@
+xosview (1.8.3+debian-11-tli1) unstable; urgency=low
+
+ * debian/patches/24_enhanced_mem.dpatch
++ added mem values for slab, mapped, and page tables
+
+ -- Ryan Thoryk r...@tliquest.net Wed, 26 Nov 2008 12:56:45 -0600
+
xosview (1.8.3+debian-11) unstable; urgency=low
* debian/patches/23_cpumeter_guest_time.dpatch:
diff -urN xosview-1.8.3+debian.old/debian/patches/00list xosview-1.8.3+debian/debian/patches/00list
--- xosview-1.8.3+debian.old/debian/patches/00list 2008-11-26 13:14:53.0 -0600
+++ xosview-1.8.3+debian/debian/patches/00list 2008-11-26 13:15:50.044496544 -0600
@@ -20,3 +20,4 @@
21_fix_unclutter.dpatch
22_fix_valgrind_reports.dpatch
23_cpumeter_guest_time.dpatch
+24_enhanced_mem.dpatch
diff -urN xosview-1.8.3+debian.old/debian/patches/24_enhanced_mem.dpatch xosview-1.8.3+debian/debian/patches/24_enhanced_mem.dpatch
--- xosview-1.8.3+debian.old/debian/patches/24_enhanced_mem.dpatch 1969-12-31 18:00:00.0 -0600
+++ xosview-1.8.3+debian/debian/patches/24_enhanced_mem.dpatch 2008-11-26 13:12:19.009182000 -0600
@@ -0,0 +1,126 @@
+#!/bin/sh /usr/share/dpatch/dpatch-run
+## 24_enhanced_mem.dpatch
+## Dpatch by Ryan Thoryk r...@tliquest.net
+## DP: Additional mem values for Linux
+
+...@dpatch@
+
+diff -urN xosview-1.8.3-orig/linux/memmeter.cc xosview-1.8.3-new/linux/memmeter.cc
+--- xosview-1.8.3-orig/linux/memmeter.cc 2006-02-17 22:33:06.0 -0600
xosview-1.8.3-new/linux/memmeter.cc 2008-11-26 12:34:17.558494000 -0600
+@@ -15,7 +15,7 @@
+ static const char MEMSTATFNAME[] = /proc/memstat;
+
+ MemMeter::MemMeter( XOSView *parent )
+-: FieldMeterGraph( parent, 4, MEM, USED+SHAR/BUFF/CACHE/FREE ){
++: FieldMeterGraph( parent, 7, MEM, USED/BUFF/SLAB/MAP/PT/CACHE/FREE ){
+ _shAdj = -1;
+
+ // Check and see if the memstat module has been loaded
+@@ -43,8 +43,11 @@
+ if (_shAdj == 0)
+ setfieldcolor( 1, parent_-getResource( memSharedColor ) );
+ setfieldcolor( 2 + _shAdj, parent_-getResource( memBufferColor ) );
+- setfieldcolor( 3 + _shAdj, parent_-getResource( memCacheColor ) );
+- setfieldcolor( 4 + _shAdj, parent_-getResource( memFreeColor ) );
++ setfieldcolor( 3 + _shAdj, parent_-getResource( memSlabColor ) );
++ setfieldcolor( 4 + _shAdj, parent_-getResource( memMapColor ) );
++ setfieldcolor( 5 + _shAdj, parent_-getResource( memPTColor ) );
++ setfieldcolor( 6 + _shAdj, parent_-getResource( memCacheColor ) );
++ setfieldcolor( 7 + _shAdj, parent_-getResource( memFreeColor ) );
+ priority_ = atoi (parent_-getResource( memPriority ) );
+ dodecay_ = parent_-isResourceTrue( memDecay );
+ useGraph_ = parent_-isResourceTrue( memGraph );
+@@ -54,11 +57,12 @@
+ void MemMeter::checkevent( void ){
+ getmeminfo();
+ /* for debugging (see below)
+- printf(t %4.1f used %4.1f share %4.1f buffer %4.1f cache %4.1f free %4.1f\n,
++ printf(t %4.1f used %4.1f buffer %4.1f slab %4.1f map %4.1f pt %4.1f cache %4.1f free %4.1f\n,
+ total_/1024.0/1024.0,
+ fields_[0]/1024.0/1024.0, fields_[1]/1024.0/1024.0,
+ fields_[2]/1024.0/1024.0, fields_[3]/1024.0/1024.0,
+- fields_[4]/1024.0/1024.0);
++ fields_[4]/1024.0/1024.0, fields_[5]/1024.0/1024.0,
++ fields_[6]/1024.0/1024.0);
+ */
+ drawfields();
+ }
+@@ -76,11 +80,11 @@
+ // without this fix used sometimes gets 0 !
+ fields_[0] = total_ - fields_[4] - fields_[3] - fields_[2] - fields_[1];
+ }else{
+-fields_[0] = total_ - fields_[3] - fields_[2] - fields_[1];
++fields_[0] = total_ - fields_[6] - fields_[5] - fields_[4] - fields_[3] - fields_[2] - fields_[1];
+ }
+
+ if (total_)
+-FieldMeterDecay::setUsed (total_ - fields_[4 + _shAdj], total_);
++FieldMeterDecay::setUsed (total_ - fields_[7 + _shAdj], total_);
+ }
+
+ MemMeter::LineInfo *MemMeter::findLines(LineInfo *tmplate, int len,
+@@ -116,9 +120,12 @@
+ void MemMeter::initLineInfo(void){
+ static LineInfo infos[] = {
+ LineInfo(MemTotal, total_),
+-LineInfo(MemFree, fields_[4 + _shAdj]),
++LineInfo(MemFree, fields_[7 + _shAdj]),
+ LineInfo(Buffers
Bug#507577: xosview: dpatch for additional mem fields
Package: xosview
Version: 1.8.3+debian-11
Severity: wishlist
Tags: patch
I created a patch that adds memory fields for SLAB, mapped files, and page
tables. It's mainly for the SLAB field, since if the SLAB cache gets very
large (let's say 1/3 of the system's ram or more), users might either
think that their apps are taking up that amount of memory or that there
might be a kernel leak.
This patch will only work with 2.6 kernels that list the fields Slab,
Mapped, and PageTables in /proc/meminfo.
Ryan Thoryk
System Administrator
onShore Networks, LLC
[EMAIL PROTECTED]
[EMAIL PROTECTED]#!/bin/sh /usr/share/dpatch/dpatch-run
## 24_enhanced_mem.dpatch
## Dpatch by Ryan Thoryk [EMAIL PROTECTED]
## DP: Additional mem values for Linux
@DPATCH@
diff -urN xosview-1.8.3-orig/linux/memmeter.cc
xosview-1.8.3-new/linux/memmeter.cc
--- xosview-1.8.3-orig/linux/memmeter.cc2006-02-17 22:33:06.0
-0600
+++ xosview-1.8.3-new/linux/memmeter.cc 2008-11-26 12:34:17.558494000 -0600
@@ -15,7 +15,7 @@
static const char MEMSTATFNAME[] = /proc/memstat;
MemMeter::MemMeter( XOSView *parent )
-: FieldMeterGraph( parent, 4, MEM, USED+SHAR/BUFF/CACHE/FREE ){
+: FieldMeterGraph( parent, 7, MEM, USED/BUFF/SLAB/MAP/PT/CACHE/FREE ){
_shAdj = -1;
// Check and see if the memstat module has been loaded
@@ -43,8 +43,11 @@
if (_shAdj == 0)
setfieldcolor( 1, parent_-getResource( memSharedColor ) );
setfieldcolor( 2 + _shAdj, parent_-getResource( memBufferColor ) );
- setfieldcolor( 3 + _shAdj, parent_-getResource( memCacheColor ) );
- setfieldcolor( 4 + _shAdj, parent_-getResource( memFreeColor ) );
+ setfieldcolor( 3 + _shAdj, parent_-getResource( memSlabColor ) );
+ setfieldcolor( 4 + _shAdj, parent_-getResource( memMapColor ) );
+ setfieldcolor( 5 + _shAdj, parent_-getResource( memPTColor ) );
+ setfieldcolor( 6 + _shAdj, parent_-getResource( memCacheColor ) );
+ setfieldcolor( 7 + _shAdj, parent_-getResource( memFreeColor ) );
priority_ = atoi (parent_-getResource( memPriority ) );
dodecay_ = parent_-isResourceTrue( memDecay );
useGraph_ = parent_-isResourceTrue( memGraph );
@@ -54,11 +57,12 @@
void MemMeter::checkevent( void ){
getmeminfo();
/* for debugging (see below)
- printf(t %4.1f used %4.1f share %4.1f buffer %4.1f cache %4.1f free
%4.1f\n,
+ printf(t %4.1f used %4.1f buffer %4.1f slab %4.1f map %4.1f pt %4.1f cache
%4.1f free %4.1f\n,
total_/1024.0/1024.0,
fields_[0]/1024.0/1024.0, fields_[1]/1024.0/1024.0,
fields_[2]/1024.0/1024.0, fields_[3]/1024.0/1024.0,
-fields_[4]/1024.0/1024.0);
+fields_[4]/1024.0/1024.0, fields_[5]/1024.0/1024.0,
+fields_[6]/1024.0/1024.0);
*/
drawfields();
}
@@ -76,11 +80,11 @@
// without this fix used sometimes gets 0 !
fields_[0] = total_ - fields_[4] - fields_[3] - fields_[2] - fields_[1];
}else{
-fields_[0] = total_ - fields_[3] - fields_[2] - fields_[1];
+fields_[0] = total_ - fields_[6] - fields_[5] - fields_[4] - fields_[3] -
fields_[2] - fields_[1];
}
if (total_)
-FieldMeterDecay::setUsed (total_ - fields_[4 + _shAdj], total_);
+FieldMeterDecay::setUsed (total_ - fields_[7 + _shAdj], total_);
}
MemMeter::LineInfo *MemMeter::findLines(LineInfo *tmplate, int len,
@@ -116,9 +120,12 @@
void MemMeter::initLineInfo(void){
static LineInfo infos[] = {
LineInfo(MemTotal, total_),
-LineInfo(MemFree, fields_[4 + _shAdj]),
+LineInfo(MemFree, fields_[7 + _shAdj]),
LineInfo(Buffers, fields_[2 + _shAdj]),
-LineInfo(Cached, fields_[3 + _shAdj])
+LineInfo(Slab, fields_[3 + _shAdj]),
+LineInfo(Mapped, fields_[4 + _shAdj]),
+LineInfo(PageTables, fields_[5 + _shAdj]),
+LineInfo(Cached, fields_[6 + _shAdj])
};
_numMIlineInfos = sizeof(infos) / sizeof(LineInfo);
diff -urN xosview-1.8.3-orig/Xdefaults xosview-1.8.3-new/Xdefaults
--- xosview-1.8.3-orig/Xdefaults2006-02-18 19:36:08.0 -0600
+++ xosview-1.8.3-new/Xdefaults 2008-11-26 12:53:01.477496000 -0600
@@ -87,6 +87,9 @@
xosview*memUsedColor: seagreen
xosview*memSharedColor: SkyBlue
xosview*memBufferColor: orange
+xosview*memSlabColor: slateblue1
+xosview*memMapColor: lightgoldenrod
+xosview*memPTColor:lightgreen
xosview*memCacheColor: red
xosview*memFreeColor: aquamarine
xosview*memTextColor: blue
diff -urN xosview-1.8.3-orig/Xdefaults.in xosview-1.8.3-new/Xdefaults.in
--- xosview-1.8.3-orig/Xdefaults.in 2006-02-17 23:45:00.0 -0600
+++ xosview-1.8.3-new/Xdefaults.in 2008-11-26 12:37:19.204494000 -0600
@@ -87,6 +87,9 @@
xosview*memUsedColor: seagreen
xosview*memSharedColor: SkyBlue
xosview*memBufferColor: orange
+xosview*memSlabColor: blue
+xosview*memMapColor: SlateBlue1
+xosview*memPTColor:lightgreen
xosview*memCacheColor: red
xosview*memFreeColor: aquamarine
xosview*memTextColor
Bug#467609: Still not fixed
The etch6 glibc nscd updated didn't seem to fix the problem, at least for us. Currently we've created a cron script that invalidates the 3 nscd tables every 2 hours, which seems to be preventing the corruption (we use LDAP with NSS and PAM). --- Ryan Thoryk System Administrator onShore Networks, LLC completeIT® services 1407 West Chicago Avenue Chicago, Illinois 60622 312.850.5200 x146 [EMAIL PROTECTED] www.onshore.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468412: wifi-radar: Infinite save loop during runtime
Package: wifi-radar Version: 1.9.8-5 Severity: important Hi, I've been trying to get wifi-radar to run on my system (running Etch), and both the Etch version and the latest one from unstable both have this issue. Basically a save operation for the config file exists in the app's main run loop, causing it to slow to a crawl, and waste disk resources. The problematic line is line 786, which is: self.pstore.connect( 'row-changed', self.save_auto_profile_order ) It looks like it should be saving the auto profile order information whenever the list changes, but instead is saving it during every run cycle. The quick fix I did was to simply comment out that line, but by doing that the auto-order feature breaks. Thanks Ryan Thoryk System Administrator onShore Networks, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410491: wxwidgets2.6: Make wxGetKeyState() work for non-meta keys too
Package: wxwidgets2.6 Severity: important Tags: patch There's an issue with the wxGetKeyState() function (in src/unix/utilsx11.cpp), where it only works for metakeys instead of all keys (like the manual explains). The original bug report can be found at: http://sourceforge.net/tracker/index.php?func=detailaid=1521490group_id=9863atid=309863 This bug report contains the patch found on that site, which fixes the above file. Ryan Thoryk System Administrator onShore Networks, LLC [EMAIL PROTECTED] [EMAIL PROTECTED]--- utilsx11.cpp.Old2006-07-12 22:13:38.0 +0100 +++ utilsx11.cpp2006-07-13 11:02:26.0 +0100 @@ -546,4 +546,6 @@ case XK_Meta_R: id = WXK_ALT; break; +case XK_Caps_Lock: +id = WXK_CAPITAL; break; case XK_BackSpace: id = WXK_BACK; break; @@ -600,21 +602,21 @@ case XK_KP_Multiply: -id = WXK_MULTIPLY; break; +id = WXK_NUMPAD_MULTIPLY; break; case XK_KP_Add: -id = WXK_ADD; break; +id = WXK_NUMPAD_ADD; break; case XK_KP_Subtract: -id = WXK_SUBTRACT; break; +id = WXK_NUMPAD_SUBTRACT; break; case XK_KP_Divide: -id = WXK_DIVIDE; break; +id = WXK_NUMPAD_DIVIDE; break; case XK_KP_Decimal: -id = WXK_DECIMAL; break; +id = WXK_NUMPAD_DECIMAL; break; case XK_KP_Equal: -id = '='; break; +id = WXK_NUMPAD_EQUAL; break; case XK_KP_Space: -id = ' '; break; +id = WXK_NUMPAD_SPACE; break; case XK_KP_Tab: -id = WXK_TAB; break; +id = WXK_NUMPAD_TAB; break; case XK_KP_Enter: -id = WXK_RETURN; break; +id = WXK_NUMPAD_ENTER; break; case XK_KP_0: id = WXK_NUMPAD0; break; @@ -637,4 +639,22 @@ case XK_KP_9: id = WXK_NUMPAD9; break; +case XK_KP_Insert: +id = WXK_NUMPAD_INSERT; break; +case XK_KP_End: +id = WXK_NUMPAD_END; break; +case XK_KP_Down: +id = WXK_NUMPAD_DOWN; break; +case XK_KP_Page_Down: +id = WXK_NUMPAD_PAGEDOWN; break; +case XK_KP_Left: +id = WXK_NUMPAD_LEFT; break; +case XK_KP_Right: +id = WXK_NUMPAD_RIGHT; break; +case XK_KP_Home: +id = WXK_NUMPAD_HOME; break; +case XK_KP_Up: +id = WXK_NUMPAD_UP; break; +case XK_KP_Page_Up: +id = WXK_NUMPAD_PAGEUP; break; case XK_F1: id = WXK_F1; break; @@ -706,4 +726,5 @@ case WXK_CONTROL: keySym = XK_Control_L; break; case WXK_ALT: keySym = XK_Meta_L; break; +case WXK_CAPITAL: keySym = XK_Caps_Lock; break; case WXK_MENU : keySym = XK_Menu; break; case WXK_PAUSE: keySym = XK_Pause; break; @@ -724,19 +745,21 @@ case WXK_DELETE:keySym = XK_Delete; break; case WXK_HELP : keySym = XK_Help; break; -case WXK_NUMPAD0: keySym = XK_KP_0; break; -case WXK_NUMPAD1: keySym = XK_KP_1; break; -case WXK_NUMPAD2: keySym = XK_KP_2; break; -case WXK_NUMPAD3: keySym = XK_KP_3; break; -case WXK_NUMPAD4: keySym = XK_KP_4; break; +case WXK_NUMPAD0: keySym = XK_KP_0; break; case WXK_NUMPAD_INSERT: keySym = XK_KP_Insert; break; +case WXK_NUMPAD1: keySym = XK_KP_1; break; case WXK_NUMPAD_END: keySym = XK_KP_End; break; +case WXK_NUMPAD2: keySym = XK_KP_2; break; case WXK_NUMPAD_DOWN: keySym = XK_KP_Down; break; +case WXK_NUMPAD3: keySym = XK_KP_3; break; case WXK_NUMPAD_PAGEDOWN: keySym = XK_KP_Page_Down; break; +case WXK_NUMPAD4: keySym = XK_KP_4; break; case WXK_NUMPAD_LEFT: keySym = XK_KP_Left; break; case WXK_NUMPAD5: keySym = XK_KP_5; break; -case WXK_NUMPAD6: keySym = XK_KP_6; break; -case WXK_NUMPAD7: keySym = XK_KP_7; break; -case WXK_NUMPAD8: keySym = XK_KP_8; break; -case WXK_NUMPAD9: keySym = XK_KP_9; break; -case WXK_MULTIPLY: keySym = XK_KP_Multiply; break; -case WXK_ADD: keySym = XK_KP_Add; break; -case WXK_SUBTRACT: keySym = XK_KP_Subtract; break; -case WXK_DECIMAL: keySym = XK_KP_Decimal; break; -case WXK_DIVIDE:keySym = XK_KP_Divide; break; +case WXK_NUMPAD6: keySym = XK_KP_6; break; case WXK_NUMPAD_RIGHT: keySym = XK_KP_Right; break; +case WXK_NUMPAD7: keySym = XK_KP_7; break; case WXK_NUMPAD_HOME: keySym = XK_KP_Home; break; +case WXK_NUMPAD8: keySym = XK_KP_8; break; case WXK_NUMPAD_UP: keySym = XK_KP_Up; break; +case WXK_NUMPAD9: keySym
Bug#408147: xosview: incorrect search patch for X defaults file
Package: xosview Veraion: 1.8.2-10 Severity: serious Xosview doesn't properly search for the XOsview file (in app-defaults). In etch, this is at /etc/X11/app-defaults/XOsview, but the primary search path is /usr/X11R6/lib/X11/app-defaults/XOsview and there's no symlink associating the two (no app-defaults in /usr/X11R6/lib/X11), and so the config file never gets processed. Ryan Thoryk [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358044: Fixed upstream
This bug has been fixed upstream as part of a series of patches I made that fix platform issues (mainly for Solaris and IRIX). Upstream SVN: http://crystal.svn.sourceforge.net/viewvc/crystal/CS/trunk/include/cssysdef.h?r1=26026r2=26189 Original patch: http://www.tliquest.net/ryan/cs_patches/cssysdef.diff Ryan Thoryk [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341871: linux-2.6 2.6.14-4 pool timestamps a year off
Package: linux-2.6 Version: 2.6.14-4 Severity: important While manually getting the debian-patches package, I noticed that all of the 2.6.14-4 packages have timestamps a year off (11/26/04 - should be 11/26/05), while the 2.6.12-10 packages are fine (09/27/05). I don't know if this would cause any problems (unless there's date verification of the files), but someone's clock is off by a year ;) Ryan Thoryk Unix and Network Specialist [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337496: basilisk2: Always crashes when starting up (home-built version does too)
It looks like your system is using the Udev system and HAL. Those files are not automatically allocated by those systems (so would this be a bug in Basilisk or UDEV?) Udev moves them to /dev/.static/dev Ryan Thoryk Unix and Network Specialist [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
