Bug#1037385: elementary-xfce-icon-theme: gnome-netstatus-idle.png is missing in status/48
Package: elementary-xfce-icon-theme Version: 0.17-1 Severity: normal Dear Maintainer, the icon that should be called gnome-netstatus-idle is missing in the /usr/share/icons/elementary-xfce/status/48 directory. Because of that, some applications, like lxpanel, replace it with the other size of the icon, 24, for example, and it is of a different design (monitors instead of arrows) and that looks aesthetically unpleasant when two designs switch rapidly. I should not that it is not missing in sizes 24 or 22, so that's clearly a but and not a desired state. I have symlinked network-idle.png in the same directory to gnome-netstatus-idle.png and that fixed it. I suggest doing the same in the package. Thanks in advance! -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 6.1.0-9-686 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#1025383: starfighter-data: Starfighter segfaults after the last battle
Package: starfighter-data Version: 2.3.3-1 Severity: normal Dear Maintainer, First of all, thanks for making a debian package of this game, it was really fun and nice to play. But the very end of the game turned out to be quite anticlimatic. The game segfaults after beating the last boss. I took my time to investigate the cause of this segfault and apparently it happens because game fails to open its credits file: /usr/share/starfighter/data/credits.txt I found that file in /usr/share/doc/starfighter/ and I don't think it belongs there as it is not just a text file with credits, but more like a game asset. But maybe it does, so in that case could you please add a symlink like you did with TakaoPGothic.ttf? I think it will only require adding the following line into debian/starfighter.links file: /usr/share/doc/starfighter/credits.txt usr/share/starfighter/data/credits.txt Thanks in advance! -- System Information: Debian Release: 11.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-18-686 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#1023827: unifont: Include upper planes into the package
Package: xfonts-unifont Version: 1:13.0.06-1 Severity: wishlist File: unifont Dear Maintainer, I would like to suggest you to add Unifont's upper plane which is now available https://unifoundry.com/unifont/index.html here into the unifont packages. Or maybe make it a separate package, it doesn't matter much. -- System Information: Debian Release: 11.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-18-686 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xfonts-unifont depends on: ii xfonts-utils 1:7.7+6 xfonts-unifont recommends no packages. Versions of packages xfonts-unifont suggests: pn ttf-unifont -- no debconf information
Bug#997032: xserver-xorg: Lax the dependency on xserver-xorg-video-all | xorg-driver-video
Package: xserver-xorg Version: 1:7.7+22 Severity: wishlist Dear Maintainer, Nowadays with the ubiquitous usage of modesetting driver, xserver-xorg-video-* drivers are not required to run X server. I'd like to suggest X server maintainers to change the dependency of xserver-xorg package on xserver-xorg-video-all | xorg-driver-video to recommendation or maybe even a suggestion. I think it will not hurt most of the users, but those who use just the modesetting driver will be able to remove those packages. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 16 2015 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Apr 13 2021 /usr/bin/Xorg The lspci command was not found; not including PCI data. Xorg X server configuration file status: -rw-r--r-- 1 root root 2148 Oct 19 00:17 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Main" 0 0 InputDevice"Thinkpad Mouse" "CorePointer" InputDevice"Thinkpad Keyboard" "CoreKeyboard" EndSection Section "ServerFlags" Option "DontZap" "false" EndSection Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "glx" EndSection Section "InputDevice" Identifier "Thinkpad Keyboard" Driver "libinput" EndSection Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" # Those are set in /etc/default/keyboard # Option "XkbLayout" "us,ru" # Option "XkbVariant""," # Option "XkbOptions" "terminate:ctrl_alt_bksp,grp:caps_toggle,compose:ralt" EndSection Section "InputDevice" Identifier "Thinkpad Mouse" Driver "libinput" EndSection Section "InputClass" Identifier "Touchpad Defaults" MatchIsTouchpad "yes" Option "HorizontalScrolling" "no" Option "Tapping" "yes" EndSection Section "InputClass" Identifier "Trackpoint Defaults" MatchIsPointer "yes" Option "AccelSpeed""-1" EndSection Section "Device" Identifier "Intel(R) HD Graphics 3000" Driver "intel" VendorName "Intel Corporation" BoardName "N10 Family Integrated Graphics Controller" BusID "PCI:0:2:0" Option "TearFree" "yes" EndSection Section "Screen" Identifier "Main" Device "Intel(R) HD Graphics 3000" Monitor"LVDS1" SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Monitor" Identifier"LVDS1" DisplaySize 280 155 EndSection Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.10.0-9-686 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.70-1 (2021-09-30) Xorg X server log files on system: -- -rw-r--r-- 1 root root 29739 Feb 8 2016 /var/log/Xorg.2.log -rw-r--r-- 1 root root 27438 May 19 2020 /var/log/Xorg.0.log -rw-r--r-- 1 root root 7301 Aug 7 2020 /var/log/Xorg.1.log -rw-r--r-- 1 root root 7301 Aug 7 2020 /var/log/Xorg.3.log -rw-r--r-- 1 sqrt sqrt 6219 Oct 18 23:01 /home/sqrt/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 sqrt sqrt 6700 Oct 21 20:21 /home/sqrt/.local/share/xorg/Xorg.2.log -rw-r--r-- 1 sqrt sqrt 25075 Oct 21 20:22 /home/sqrt/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/sqrt/.local/share/xorg/Xorg.0.log): - [279828.657] X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 [279828.662] Build Operating System: linux Debian [279828.663] Current Operating System: Linux laptop 5.10.0-9-686 #1 SMP Debian 5.10.70-1 (2021-09-30) i686 [279828.663] Kernel command line: BOOT_IMAGE=/vmlinuz quiet initrd=/initrd.img resume=/dev/sda2 root=/dev/sda1 [279828.667] Build Date: 13 April 2021 04:07:31PM [279828.668] xorg-server 2:1.20.11-1 (https://www.debian.org/support) [279828.670] Current version of pixman: 0.40.0 [279828.673]Before reporting problems, check http://wiki.x.org to make sure that
Bug#993459: openssh-server: sshd's PAM configuration doesn't set $MAIL
Package: openssh-server Version: 1:8.4p1-5 Severity: normal Dear Maintainer, After upgrading from Buster to Bullseye, I've noticed that $MAIL variable is not set when one logs in via ssh, but is set when one logs in on TTY. I don't think it was an intended behaviour. I've looked through the possible places where it could be set and found out that it was previously set in /etc/login.defs, but now is governed by PAM. Further investigation showed that PAM configuration for sshd which resides in /etc/pam.d/sshd has the line sessionoptional pam_mail.so standard noenv # [1] I've changed it to sessionoptional pam_mail.so standard # [1] and now the $MAIL is set again. Searching for the reason to set `noenv' there led me to this bug in BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58429 In this bug it was reported that there were multiple non-informative entries in auth.log if `noenv` was not enabled, but the bug was filed more than 20 years ago, so I've checked if it is still the case. Apparently it is not, the only new lines in auth.log are Sep 1 19:42:14 laptop sshd[28790]: Accepted publickey for sqrt from 127.0.0.1 port 50194 ssh2: RSA SHA256:oCn47IKkSvC9WS1aUl52hD0UYsVtDT80s9pFDETWac0 Sep 1 19:42:14 laptop sshd[28790]: pam_unix(sshd:session): session opened for user sqrt(uid=1000) by (uid=0) So I suggest we revert this `noenv' option as the reason for its existing is gone and it causes problems like the one I'm filing this bug about. Thanks in advance! -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-8-686 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.77 ii dpkg 1.20.9 ii libaudit1 1:3.0-2 ii libc6 2.31-13 ii libcom-err21.46.2-2 ii libcrypt1 1:4.4.18-4 ii libgssapi-krb5-2 1.18.3-6 ii libkrb5-3 1.18.3-6 ii libpam-modules 1.4.0-9 ii libpam-runtime 1.4.0-9 ii libpam0g 1.4.0-9 ii libselinux13.1-3 ii libssl1.1 1.1.1k-1 ii libsystemd0247.3-6 ii libwrap0 7.6.q-31 ii lsb-base 11.1.0 ii openssh-client 1:8.4p1-5 ii openssh-sftp-server1:8.4p1-5 ii procps 2:3.3.17-5 ii runit-helper 2.10.3 ii ucf3.0043 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages openssh-server recommends: pn default-logind | logind | libpam-systemd pn ncurses-term ii xauth 1:1.1-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass pn ufw -- Configuration Files: /etc/pam.d/sshd changed: @include common-auth accountrequired pam_nologin.so @include common-account session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close sessionrequired pam_loginuid.so sessionoptional pam_keyinit.so force revoke @include common-session sessionoptional pam_motd.so motd=/run/motd.dynamic sessionoptional pam_motd.so noupdate sessionoptional pam_mail.so standard # [1] sessionrequired pam_limits.so sessionrequired pam_env.so # [1] sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open @include common-password -- debconf-show failed
Bug#983121: tiny-initramfs: Add hibernation support to tiny-initramfs
Package: tiny-initramfs
Version: 0.1-5
Severity: wishlist
Tags: patch upstream
Dear Maintainer,
I'd like to use tiny-initramfs because it suits my needs very well, and
makes my computer boot a bit faster and thus makes me feel happier :)
The only issue I found with this nice piece of software is that it
doesn't allow me to resume from hibernation. So I looked into the code
of the tiny-initramfs and it turned out that it is very easy to add this
support.
I've made a patch that adds the support for resuming from hibernation,
and I'm attaching it to the bug report. It would be nice if someone
checked it for errors, since last time I wrote something substantial in
C was years ago. Anyway, it works fine for me (built my own package
with this patch) and it would be nice to help someone else who has the
same problem.
I'm aware that this has no chance to be included in bullseye, but oh
well.
Thanks in advace!
-- System Information:
Debian Release: 10.8
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 4.19.0-14-686 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages tiny-initramfs depends on:
ii tiny-initramfs-core 0.1-5
tiny-initramfs recommends no packages.
tiny-initramfs suggests no packages.
-- no debconf information
Description: Make tirfs able to resume from hibernation
Author: Mikhail Krylov
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/tiny_initramfs.c
+++ b/tiny_initramfs.c
@@ -64,6 +64,7 @@ static char root_nfsdir[MAX_LINE_LEN];
static char root_nfsoptions[MAX_LINE_LEN];
#endif
static char root_fstype[MAX_FILESYSTEM_TYPE_LEN];
+static char resume_device[MAX_FILESYSTEM_TYPE_LEN];
static int root_delay;
static int root_wait_indefinitely;
static char init_binary[MAX_PATH_LEN];
@@ -112,6 +113,37 @@ int main(int argc, char **argv)
warn("Parsed ", PROC_CMDLINE_FILENAME, NULL);
#endif
+ if (!strlen(resume_device)){
+
+#ifdef ENABLE_DEBUG
+warn("No resume device specified");
+#endif
+
+ } else {
+// We won't need /target on a successful resume
+r = mount("sysfs", "/target", "sysfs", MS_NODEV | MS_NOEXEC | MS_NOSUID,
NULL);
+if (r < 0)
+ panic(errno, "Could not mount /target for hibernation resume", NULL);
+
+#ifdef ENABLE_DEBUG
+warn("Mounted /target for hibernation resume", NULL);
+#endif
+
+int fd = open("/target/power/resume", O_WRONLY);
+
+if (fd < 0) {
+ warn("Couldn't open /target/power/resume", strerror(errno), NULL);
+ // Continue just like nothing happened
+ umount("/target");
+}
+
+write(fd, resume_device, strlen(resume_device));
+close(fd);
+// If we are still here, that means resume failed, continue booting
+umount("/target");
+ }
+
+
if (!strlen(root_device)) {
#ifdef ENABLE_NFS4
if (strlen(root_nfshost))
@@ -366,6 +398,11 @@ int parse_cmdline_helper(void *data, const char *line, int
line_is_incomplete)
if (strlen(token) > MAX_PATH_LEN - 1)
panic(0, "Parameter init=", token, " too long", NULL);
set_buf(init_binary, MAX_PATH_LEN, token, NULL);
+} else if (!strncmp(token, "resume=", 7)){
+ token += 7;
+ if (strlen(token) > MAX_PATH_LEN - 1)
+panic(0, "Parameter resume=", token, " too long", NULL);
+ set_buf(resume_device, MAX_PATH_LEN, token, NULL);
}
#ifdef ENABLE_NFS4
else if (!strncmp(token, "nfsroot=", 8)) {
Bug#979682: startpar: Is it running anything in parallel?
Package: startpar Version: 0.61-1 Severity: important Dear Maintainer, I get a feeling that startpar doesn't work as it was intended. That is, it doesn't parallel the service starting at the boot. I've conducted a couple of experiments: first, with makefile-style boot and startpar (the default one) and second, without startpar, by creating the /etc/init.d/.legacy-bootordering file. Both of them yielded about the same time, 21±1 sec for me. More than that, after reading its man page, I've tried to run startpar this way: /lib/startpar/startpar sleep sleep sleep -a 10 And sure enough, it starts three sleep processes one by one and finishes after 30 seconds instead of 10. I might be wrong, but doesn't this mean that startpar is basically useless now? -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-13-686 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages startpar depends on: ii libc6 2.28-10 startpar recommends no packages. Versions of packages startpar suggests: ii insserv 1.18.0-2 ii sysv-rc 2.93-8 -- no debconf information
Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running
Package: popularity-contest Version: 1.67 Severity: normal Dear Maintainer, I have noticed that my recent submissions to popularity contest database have failed. After some further investigation and running sudo bash -x /etc/cron.daily/popularity-contest to see what is actually happening, I've noticed that it tries to use torify to send the submission: /usr/bin/torify /usr/share/popularity-contest/popcon-upload -u http://popcon.debian.org/cgi-bin/popcon.cgi -f /var/log/popularity-contest.new.gpg Although I have tor installed, I don't run it all the time, and only start it on demand. For now, as a workaround, I set USETOR="no". I suggest that this script would check the `service tor status` before actually using torify if USETOR="maybe" and fail if USERTOR="yes". Thanks in advance! -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-9-686 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages popularity-contest depends on: ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 Versions of packages popularity-contest recommends: ii cron [cron-daemon] 3.0pl1-134+deb10u1 pn default-mta | mail-transport-agent ii gnupg 2.2.12-1+deb10u1 Versions of packages popularity-contest suggests: ii anacron 2.3-28 ii tor 0.3.5.10-1 ii torsocks 2.3.0-2 -- debconf information: * popularity-contest/participate: true popularity-contest/submiturls:
Bug#945252: bsdmainutils: [calendar] Using non-Russian locale ignores the month in Russian calendar
Package: bsdmainutils Version: 11.1.2+b1 Severity: important Tags: l10n Dear Maintainer, calendar program, if one uses non-RU locale (maybe it's ok with other cyrillic ones, like Ukrainian), Russian holidays are displayed regardless of the month. For example: $ LANG=en_GB.UTF8 calendar -t 1125 | grep Татьянин Nov 25 Татьянин день. Студенческий праздник which is not correct, it's in January 25th, and it has a correct entry in the calendar file: $ grep Татьянин /usr/share/calendar/ru_RU/calendar.common 25 янв. Татьянин день. Студенческий праздник But if you set $LANG to ru_RU.UTF8, it is ok: $ LANG=ru_RU.UTF8 calendar -t 1125 | grep Татьянин $ I have a hunch that it is caused by the date translations in the database. Maybe it should be kept in english (neutral, C) date format? Thanks in advance! -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-6-686 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages bsdmainutils depends on: ii bsdutils 1:2.33.1-0.1 ii debianutils 4.8.6.1 ii libbsd0 0.9.1-2 ii libc62.28-10 ii libtinfo66.1+20181013-2+deb10u2 bsdmainutils recommends no packages. Versions of packages bsdmainutils suggests: ii cpp 4:8.3.0-1 pn vacation pn wamerican | wordlist pn whois -- no debconf information
Bug#932577: /usr/games/supertux2: Progress on the first world resets after returning from the second world
Package: supertux Version: 0.6.0-1 Severity: important File: /usr/games/supertux2 Dear Maintainer, I've noticed a serious bug in the game. Basically, what you have to do is: 1. Complete first (ice) world (either by playing or by editing ~/.local/share/supertux2/profile1/world1.stsg and setting all the "solved" variables to #t) 2. Go to the second (forest) world. Complete it also. 3. Get back to the first world. After coming to the first world you'll stop on the Crystal Cave level, and all of the levels in the first world will be marked as not completed. I assume that's a bug, you should be able to return to the completed levels, although it's a great game and completing it again and again is a pleasure :) If you peek into ~/.local/share/supertux2/profile1/world1.stsg again, you will notice that there appeared a second copy of the first world list and apparently game uses that to determine your progress on the first world. Thanks in advance! -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-5-686 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages supertux depends on: ii libboost-date-time1.67.0 1.67.0-13 ii libboost-filesystem1.67.0 1.67.0-13 ii libboost-locale1.67.0 1.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libc6 2.28-10 ii libcurl3-gnutls7.64.0-4 ii libfreetype6 2.9.1-3 ii libgcc11:8.3.0-6 ii libgl1 1.1.0-1 ii libglew2.1 2.1.0-4 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libogg01.3.2-1+b1 ii libopenal1 1:1.19.1-1 ii libpng16-161.6.36-6 ii libraqm0 0.5.0-1 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libsdl2-image-2.0-02.0.4+dfsg1-1 ii libstdc++6 8.3.0-6 ii libvorbis0a1.3.6-2 ii libvorbisfile3 1.3.6-2 ii supertux-data 0.6.0-1 ii zlib1g 1:1.2.11.dfsg-1 supertux recommends no packages. supertux suggests no packages. -- no debconf information
Bug#931823: laptop-mode-tools: HDD doesn't wake up when CONTROL_MOUNT_OPTIONS=1
Package: laptop-mode-tools Version: 1.72-3 Severity: important Dear Maintainer, after updating to buster, I've noticed quite an annoying problem: after waking up from suspend, my laptop (that's a Lenovo X220i) doesn't wake up the hard drive, which basically leads to totally unresponding system that can be only hard-rebooted or rebooted with Alt-SysRq-B. It doesn't happen every time, it happens maybe one in 2 or 3 wakeups. This didn't occur in stretch and I guess it shouldn't be like that :) I've noticed (by running htop, suspending, and waking up from suspend) that it is caused either directly by laptop-mode-tools which is triggered by udev, or by one of the tools it starts after resuming from suspend. I did a little research on that using the following method: 1. Change a setting in /etc/laptop-mode/laptop-mode.conf 2. Run something that will make HDD busy (cat /dev/sda > /dev/zero for example) 3. Suspend and wake up 2 or 3 times 4. See if HDD wakes up. By such experimentation, I managed to find out that the option that causes this problem is CONTROL_MOUNT_OPTIONS. If it is set to 1, one in 2 or 3 wakeups lead to sleepy HDD. But if it is set to 0, even 20 suspends/wakeups are successful. I also noted that it happens only when the laptop is on battery, but I'm not sure of that. I guess that's quite a broad description, and I'll be glad to help you with testing various options, if it is possible. For now, I guess I'll leave CONTROL_MOUNT_OPTIONS=0, but that's probably defies the idea behind laptop-mode-tools, at least in terms with HDD. Thank you in advance, Michael Krylov. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.19.0-5-686 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages laptop-mode-tools depends on: ii lsb-base10.2019051400 ii psmisc 23.2-1 ii util-linux 2.33.1-0.1 Versions of packages laptop-mode-tools recommends: ii ethtool 1:4.19-1 ii hdparm 9.58+ds-1 pn net-tools ii python3-pyqt5 5.11.3+dfsg-1+b3 ii rfkill 2.33.1-0.1 pn sdparm ii udev241-5 ii wireless-tools 30~pre9-13 Versions of packages laptop-mode-tools suggests: ii acpid 1:2.0.31-1 -- Configuration Files: /etc/laptop-mode/conf.d/intel_pstate.conf changed: DEBUG=0 CONTROL_INTEL_PSTATE=0 NOLM_AC_INTEL_PSTATE_PERF_MIN_PCT=0 # Minimum performance, in percent NOLM_AC_INTEL_PSTATE_PERF_MAX_PCT=100 # Maximum performance, in percent NOLM_AC_INTEL_PSTATE_NO_TURBO=0 # Disable "Turbo Boost"? LM_AC_INTEL_PSTATE_PERF_MIN_PCT=0 # Minimum performance, in percent LM_AC_INTEL_PSTATE_PERF_MAX_PCT=100 # Maximum performance, in percent LM_AC_INTEL_PSTATE_NO_TURBO=0 # Disable "Turbo Boost"? BATT_INTEL_PSTATE_PERF_MIN_PCT=0 # Minimum performance, in percent BATT_INTEL_PSTATE_PERF_MAX_PCT=100 # Maximum performance, in percent BATT_INTEL_PSTATE_NO_TURBO=0 # Disable "Turbo Boost"? /etc/laptop-mode/laptop-mode.conf changed: ENABLE_LAPTOP_MODE_TOOLS=1 VERBOSE_OUTPUT=0 LOG_TO_SYSLOG=1 DEBUG=0 ENABLE_LAPTOP_MODE_ON_BATTERY=1 ENABLE_LAPTOP_MODE_ON_AC=0 ENABLE_LAPTOP_MODE_WHEN_LID_CLOSED=0 ENABLE_AUTO_MODULES=1 MINIMUM_BATTERY_CHARGE_PERCENT=3 DISABLE_LAPTOP_MODE_ON_CRITICAL_BATTERY_LEVEL=1 DISABLE_BATTERY_ALARM_CHECK=0 HD="/dev/[hs]d[abcdefgh]" PARTITIONS="auto /dev/mapper/* /dev/dm-*" ASSUME_SCSI_IS_SATA=1 LM_BATT_MAX_LOST_WORK_SECONDS=600 LM_AC_MAX_LOST_WORK_SECONDS=360 CONTROL_READAHEAD=1 LM_READAHEAD=3072 NOLM_READAHEAD=128 CONTROL_NOATIME=0 USE_RELATIME=1 CONTROL_HD_IDLE_TIMEOUT=1 LM_AC_HD_IDLE_TIMEOUT_SECONDS=20 LM_BATT_HD_IDLE_TIMEOUT_SECONDS=20 NOLM_HD_IDLE_TIMEOUT_SECONDS=7200 CONTROL_HD_POWERMGMT="auto" BATT_HD_POWERMGMT=1 LM_AC_HD_POWERMGMT=254 NOLM_AC_HD_POWERMGMT=254 CONTROL_HD_WRITECACHE=0 NOLM_AC_HD_WRITECACHE=1 NOLM_BATT_HD_WRITECACHE=0 LM_HD_WRITECACHE=0 CONTROL_MOUNT_OPTIONS=0 LM_DIRTY_RATIO=60 NOLM_DIRTY_RATIO=40 LM_DIRTY_BACKGROUND_RATIO=1 NOLM_DIRTY_BACKGROUND_RATIO=10 DEF_UPDATE=5 DEF_XFS_AGE_BUFFER=15 DEF_XFS_SYNC_INTERVAL=30 DEF_XFS_BUFD_INTERVAL=1 DEF_MAX_AGE=30 XFS_HZ=100 LM_SECONDS_BEFORE_SYNC=2 -- no debconf information
Bug#890718: qemu-system: Please do not list all architectures as dependencies
On Sun, Feb 18, 2018 at 10:35:33PM +0300, Michael Tokarev wrote: > There aren't that many packages which depend on qemu-system. Actually there's > just one, which is qemubuilder. This one can depend on particular qemu > architecture if needed, and suggest/recommend others, based on their > knowledge of how it is used most. > > qemuctl depends on qemu, and as far as I can tell, is an old package which > hasn't been updated since 2011, and appears to be dead. It can be made > to depend on particular qemu-system package which it uses, or just dropped > from Debian. just like qemu-launcher. > > There are a few other packages which depend on qemu (2 or 3), and I guess > it is wrong, they actually need to depend on particular _part_ of qemu, > not _whole_ qemu. For example, nova-compute-qemu (it definitely needs > some of qemu-system-*, I've no idea which one) and os-autoinst (I can't > say what it actually needs). > > In all cases it is the other package's job to list actual dependencies, > because we on qemu side don't know anything about how these packages > use qemu. > > Either way, I don't see why we should think what "most people" need. > The way you suggest to handle this is definitely wrong, since, for > example, on aarch64 they actually need qemu-system-arm most often, > not qemu-system-x86. And once again, the packages which uses qemu > are the ones to choose. > > qemu-system package is historical. Once upon a time there was just > one package, qemu, which included everything. Now it is a transitional > package, split into qemu-system and qemu-user. And later on, qemu-system > has been split into several arch-specific packages, and qemu-system > become mostly transitional, just like qemu itself. No one actually > want to install "qemu" package, because it is quite rare to need > everything of it. No one actually want to install qemu-system either, > once again, because they only need one particular architecture, but > we don't really know which one. And I seriously thinking about dropping > qemu-system and qemu packages entirely. > > So I think the whole point is a bit moot... > > Thanks, > > /mjt I see your point. I guess dropping qemu and qemu-system package makes more sense. signature.asc Description: PGP signature
Bug#890718: Leaving qemu-system-misc
OK, so, my idea will be something like that:
|debcheckout qemu-system
|cd qemu
|vi debian/control-in
|git diff
diff --git a/debian/control-in b/debian/control-in
index 19b68e8a6d..461b197c59 100644
--- a/debian/control-in
+++ b/debian/control-in
@@ -142,7 +142,8 @@ Description: fast processor emulator
Package: qemu-system
Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sparc sparc64 x32
Multi-Arch: foreign
-Depends: ${misc:Depends},
+Depends: ${misc:Depends}
+Recommends:
qemu-system-arm,
qemu-system-mips,
qemu-system-ppc,
On Sun, Feb 18, 2018 at 07:49:56PM +0100, Geert Stappers wrote:
> On Sun, Feb 18, 2018 at 09:06:41PM +0300, Michael Krylov wrote:
> > why you left qemu-system-misc in, can you please explain?
>
> I didn't recognise a computer architecture in "-misc".
> For "-arm", "-mips" and such I did recognise the arch.
>
> I did see / read the "-misc" as short for 'miscellaneous'.
> As a package with miscellaneous files for qemu-system.
>
> Yes, I can be wrong. Feel free to update (or ignore) my patch.
>
>
> Cheers
> Geert Stappers
signature.asc
Description: PGP signature
Bug#890718: Leaving qemu-system-misc
Hm, I can't say that I understand why you left qemu-system-misc in Depends... AFAICT, it has the most peculiar architectures for emulation, and probably least desired for installation for most people. But maybe I'm wrong, can you please explain? signature.asc Description: PGP signature
Bug#840985: xdg-utils: Problem with multiple Execs in the .desktop file
Yeah, I can confirm that in Stretch it works fine. Thanks! signature.asc Description: PGP signature
Bug#866337: PAE doesn't resume from hibernate at all
One more thing I discovered today is that the -pae version of the kernel doesn't hibernate even with nokaslr. Don't know if it is related, but maybe it helps. signature.asc Description: PGP signature
Bug#866337: Help text for kASLR still says it's incompatible with hibernation
> This text is incorrect; KASLR and hibernation have been compatible > since these changes in Linux 4.8: [...] That's great news, but, I'm afraid that's only partly true. As I wrote in the initial message, my laptop, Lenovo Thinkpad x220i, is unable to wake up from hibernation unless nokaslr was added to the kernel options (or the kernel was re-compiled to disable it). So this means that on some hardware there are still some problems. Should I create a new bug or we can reopen this one?
