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
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
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
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
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
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
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
+++
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
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
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
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
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
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
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:
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
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
16 matches
Mail list logo
