Bug#1056290: systemd-homed should require libnss-systemd
Package: systemd-homed Version: 254.5-1~bpo12+2 Severity: normal Hello, I recently tried to manage a local user account through systemd-homed, and noticed that it isn't operable without libnss-systemd and the associated changes to /etc/nsswitch.conf, as mentioned in the nss-systemd(8) man page. I would probably be useful to always have libnss-systemd installed together with systemd-homed. Alex. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi6-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP 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: systemd (via /run/systemd/system) Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.38.1-5+b1 ii libc62.36-9+rpt2+deb12u3 ii libcap2 1:2.66-4 ii libfdisk12.38.1-5+b1 ii libp11-kit0 0.24.1-2 ii libpam-runtime 1.5.2-6+rpt2+deb12u1 ii libpam0g 1.5.2-6+rpt2+deb12u1 ii libssl3 3.0.11-1~deb12u2+rpt1 ii libsystemd-shared254.5-1~bpo12+2 ii systemd 254.5-1~bpo12+2 ii systemd-userdbd 254.5-1~bpo12+2 systemd-homed recommends no packages. systemd-homed suggests no packages. -- no debconf information
Bug#1056166: systemd-homed: `passwd` fails
Package: systemd-homed Version: 254.5-1~bpo12+2 Followup-For: Bug #1056166 Hello, I can confirm this problem still exists in bookworm and bookworm-backports: As soon as the Debian systemd-homed PAM configuration is activated by pam-auth-update, it's not possible to change passwords of users that come from /etc/passwd anymore. This seems to be due to a PAM misconfiguration. I don't understand enough of the Debian PAM setup to say why it doesn't work, but I tried replacing the rules with alternatives that I copied from an openSUSE Tumbleweed install, and using those it's possible to change details on users both from /etc/passwd and systemd-homed. Alex. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 6.1.0-rpi6-rpi-v8 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP 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: systemd (via /run/systemd/system) Versions of packages systemd-homed depends on: ii init-system-helpers 1.65.2 ii libblkid12.38.1-5+b1 ii libc62.36-9+rpt2+deb12u3 ii libcap2 1:2.66-4 ii libfdisk12.38.1-5+b1 ii libp11-kit0 0.24.1-2 ii libpam-runtime 1.5.2-6+rpt2+deb12u1 ii libpam0g 1.5.2-6+rpt2+deb12u1 ii libssl3 3.0.11-1~deb12u2+rpt1 ii libsystemd-shared254.5-1~bpo12+2 ii systemd 254.5-1~bpo12+2 ii systemd-userdbd 254.5-1~bpo12+2 systemd-homed recommends no packages. systemd-homed suggests no packages. -- no debconf information
Bug#605279: (csh: LINES/COLUMNS leaks into tmux global environment, leading to display problems)
Hi, ...on Sun, Apr 10, 2011 at 12:59:43PM +0200, Karl Ferdinand Ebert wrote: On Thursday 07 of April 2011 23:14:20 Alexander Bochmann wrote: The workaround I described in the original report (commenting out the two statements setenv COLUMNS and setenv LINES from both /etc/csh.login and /etc/csh.cshrc provided by the tcsh package) seems to reliably solve the problem though, so I have to admit I didn't try to debug it any further. Please let me know if I can reassign or close this bug. Thanks. I think it's best to close this bug. Thanks for your support, Alex Bochmann. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553528: munin-limits contacts bug fixed in upstream
Hi, this bug seems to have been fixed in the munin code last year: http://munin-monitoring.org/changeset/3598 Manually applying this change to the Debian munin version seems to work fine. Best regards, Alex Bochmann. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605279: (csh: LINES/COLUMNS leaks into tmux global environment, leading to display problems)
Hi, ...on Thu, Apr 07, 2011 at 12:41:49PM +0200, Karl Ferdinand Ebert wrote: Could you provide us with additional information about your shell configuration as requested by the last email from Romain? Sorry, I seem to have missed that mail. Thanks for the extensive reply. I agree that the problem is probably more with csh/tcsh than with tmux. The workaround I described in the original report (commenting out the two statements setenv COLUMNS and setenv LINES from both /etc/csh.login and /etc/csh.cshrc provided by the tcsh package) seems to reliably solve the problem though, so I have to admit I didn't try to debug it any further. Do you think I should ask the tcsh maintainers if they would remove those two statements from the global rc files? Best regards, Alex Bochmann. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606398: package dma does not provide /usr/lib/sendmail
Package: dma Version: 0.0.2010.06.17-6 Severity: normal Some programs (for example mailx from heirloom-mailx) expect to find a sendmail binary in /usr/lib/sendmail. Sending mails via mailx fails when dma is installed, as this file is missing. On a Debian system with an actual sendmail installed, the following links exist (although no package claims ownership of /usr/lib/sendmail): lrwxrwxrwx 1 root root 30 Oct 18 21:15 /usr/lib/sendmail - /etc/alternatives/lib.sendmail lrwxrwxrwx 1 root root 24 Oct 18 21:15 /etc/alternatives/lib.sendmail - /usr/lib/sm.bin/sendmail -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dma depends on: ii debconf [debconf-2.0] 1.5.36 Debian configuration management sy ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii liblockfile1 1.08-4 NFS-safe locking library, includes ii libssl0.9.8 0.9.8o-3 SSL shared libraries Versions of packages dma recommends: ii dma-migrate 0.0.2010.06.17-6 migration utility for the DragonFl ii safecat 1.13-1 safely copy stdin to a file dma suggests no packages. -- Configuration Files: /etc/dma/auth.conf [Errno 13] Permission denied: u'/etc/dma/auth.conf' /etc/dma/dma.conf [Errno 13] Permission denied: u'/etc/dma/dma.conf' /etc/dma/virtusertable [Errno 13] Permission denied: u'/etc/dma/virtusertable' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605272: suck: variable name confusion in /usr/sbin/get-news
Package: suck
Version: 4.3.2-6
Severity: normal
get-news reads rpostoptions from the config file, but uses
rpostopts to build the command line for rpost, so rpostoptions
from get-news.conf will never be used.
Patch:
--- /usr/sbin/get-news.orig 2010-11-22 00:18:02.662516320 +0100
+++ /usr/sbin/get-news 2010-11-22 00:18:29.501580780 +0100
@@ -288,7 +288,7 @@
my $postcmd = $var{'bindir'}/rpost $var{'remoteserver'}
. -N $var{'remoteport'} $authopts -E $var{'logdir'}/errlog
- . $var{'rpostopts'} -b $outgoingnew -p $artdir
+ . $var{'rpostoptions'} -b $outgoingnew -p $artdir
. -f $var{'postfilter'} \\\$\\\$o=$outfile
. \\\$\\\$i $outfile;
print LOG ts().Posting outgoing articles\n;
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32.23-grsec (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages suck depends on:
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libssl0.9.8 0.9.8o-3 SSL shared libraries
Versions of packages suck recommends:
ii perl 5.10.1-16 Larry Wall's Practical Extraction
Versions of packages suck suggests:
ii cnews [news-transport cr.g7-40.4 simple news server for Usenet news
ii lynx-cur [news-reader 2.8.8dev.5-1 Text-mode WWW Browser with NLS sup
ii tin [news-reader] 1:1.9.6~20100522-1 A full-screen easy to use Usenet n
-- Configuration Files:
/etc/suck/get-news.conf changed [not included]
/etc/suck/suckkillfile [Errno 2] No such file or directory:
u'/etc/suck/suckkillfile'
/etc/suck/sucknewsrc changed [not included]
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605279: csh: LINES/COLUMNS leaks into tmux global environment, leading to display problems
Package: tmux Version: 1.3-1 Severity: normal When tmux is used with csh/tcsh on Debian, the initial values of the COLUMNS and LINES environment variables leak into tmux' global environment, and therefore into the environment of each new window in the session. Every terminal application that relies on these variables (mutt being an example) will have a garbled display when being started after the terminal has been resized from it's original size. The bug was previously filed as 602674, before I understood why the problem occurs. Reproduction: A user with csh or tcsh as login shell starts tmux and resizes the terminal. All new tmux windows will have the original COLUMNS and LINES values from before resizing the terminal in their environment. The original values show up when running tmux show-environment -g. Workaround: Both /etc/csh.cshrc and /etc/csh.login on Debian contain the following two statements: setenv COLUMNS setenv LINES When these lines are removed, the COLUMNS and LINES variables disappear from tmux' global environment and everything works as expected. While it's possible to change the shell rc and login files, I think something in the line of blacklisting these variables from tmux's global environment would be a more thorough solution. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32.23-grsec (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages tmux depends on: ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libncurses5 5.7+20100313-4 shared libraries for terminal hand tmux recommends no packages. tmux suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605279: (csh: LINES/COLUMNS leaks into tmux global environment, leading to display problems)
Hi, the problem still exists in 1.3-2. Correction to the initial description: With mutt, it manifests itself right away without resizing the terminal, as the status line makes the terminal shorter by one line. Resizing actually helps for the active window, as LINES and COLUMNS get overwritten with the correct new window size. There's also a few SSH variables in the global tmux environment, which always stay at their initial values, even when connecting from other hosts: REMOTEHOST SSH_CLIENT SSH_CONNECTION I don't know of any software (besides maybe wireshark) which makes use of these, though... Alex. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602674: wrong terminal size in tmux new-window
Package: tmux Version: 1.3-1 Severity: normal Programs run via tmux new-window get a wrong terminal size. My test case looks like this (from within a tmux session): tmux neww stty --all | grep rows; set | grep LINES ; sh speed 38400 baud; rows 39; columns 120; line = 0; LINES='40' (LINES should be 39.) In some programs (mutt, for example), this leads to rendering problems as they use the wrong terminal size. When I look at LINES again from within the shell that is started in the above command, it will still be 40 when using dash, but it's reset to 39 when the shell is bash or tcsh (both of those seem to set LINES and COLUMNS explicitly in their respective rc files). -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32.23-grsec (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages tmux depends on: ii libc6 2.11.2-6+squeeze1 Embedded GNU C Library: Shared lib ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libncurses55.7+20100313-4shared libraries for terminal hand tmux recommends no packages. tmux suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602674: wrong terminal size in tmux new-window
Please disregard this bugreport, as I couldn't reproduce it on another Debian squeeze system: There is no output on the set | grep LINES part (same on an OpenBSD system with tmux). Moreover, I noticed that the variable stays at 40 regardless of the actual terminal size on this machine, so I assume it must be some local artifact (although I currently have no idea where it may originate). Sorry, Alex Bochmann. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551566: (/etc/hylafax mount bug still present in 6.0.4-10)
Hi,
...on Mon, Aug 30, 2010 at 11:46:29PM +0200, Giuseppe Sacco wrote:
Could you check if these commands work at a root prompt?
# ps --no-headers -C faxq -o pid
# ps --no-headers -Chfaxd,faxq,faxgetty
Same error message. But mentioning ps has reminded me of
something else, and the problem is probably rather specific
to my system... My environment for root has, historically:
PS_PERSONALITY=bsd
As soon as I unset that, everything works as expected. Doh.
Then, please, these two commands will identify ps package version:
# dpkg -S `which ps`
# apt-cache policy $(dpkg -S `which ps` | awk -F: '{print $1}')
# dpkg -S `which ps`
procps: /bin/ps
# apt-cache policy $(dpkg -S `which ps` | awk -F: '{print $1}')
procps:
Installed: 1:3.2.8-9
Candidate: 1:3.2.8-9
Version table:
*** 1:3.2.8-9 0
500 http://ftp.informatik.rwth-aachen.de squeeze/main Packages
100 /var/lib/dpkg/status
Sorry to have cluttered the bug report with this, don't know
why I didn't think of ps when seeing the error...
Best regards,
Alex.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551566: /etc/hylafax mount bug still present in 6.0.4-10
Installation of current hylafax-client in squeeze still fails unless the bind mount for /etc/hylafax is manually removed. From a quick glance at the scripts it seems that the required umount is only present for hylafax-server - but at least on my system, hylafax-client is always configured first (which doesn't work). Regards, Alex. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551566: (/etc/hylafax mount bug still present in 6.0.4-10)
After seeing Bug #551443 I noticed the underlying cause seems to be related to the initscript for me: /etc/init.d/hylafax never reaches the umountbind call in daemon_stop() on my system, as the following message is thrown before: # /etc/init.d/hylafax stop Stopping HylaFAX: faxqERROR: Unsupported option (BSD syntax) * simple selection * * selection by list * -A all processes -C by command name -N negate selection -G by real group ID (supports names) -a all w/ tty except session leaders -U by real user ID (supports names) [.. etc ..] Don't have an idea yet on what exactly the script barfs here, but the result is that /etc/hylafax is never unmounted and then hylafax-client setup fails. System is an old install that has gone through several dist-upgrades, so I assume there may be some residuals of old config data? (Don't see any .dpkg-dist files for hylafax though.) Alex. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#324536: old tabextensions preferences may crash latest mozilla-firefox update
Package: mozilla-tabextensions Version: 1.14.2005040701-1 After upgrading to the latest mozilla-firefox package in sarge (1.0.4-2sarge2) from the previous version, tabextensions segfault the browser under certain conditions (see below): ~ mozilla-firefox *** loading the extensions datasource *** loading the extensions datasource Segmentation fault When removing all old tabbrowser preferences from the configuration (all browser.tabs.extensions entries in prefs.js, the tabextensions.js file, and the tabextensions directory), firefox starts up with the tabbrowser setup window and runs fine with the fresh configuration afterwards. Unfortunately, I can not currently say which specific preference setting might be responsible for the crash. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324536: Acknowledgement (old tabextensions preferences may crash latest mozilla-firefox update)
Sorry, duplicate of #32 Addition: It seems that I can reproduce the crash when activating both the Restore the last tab session and the Restore tab session, on the next startup of crash settings on the Startup preference pane (although I currently have no saved tab sessions, at least none that I could load). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
