This is an issue when creating Debian schroot on a Ubuntu host.
It's specifically mentioned here, with a workaround:
https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Creating_the_schroots
```
Note 2: Debian schroots pull in exim4-base but Ubuntu systems do not. Due
to Debian bug #56561
On Tue, Jan 19, 2010 at 12:34:38AM +0100, Sascha Silbe wrote:
We could add logic to compare the two and merge the differences
rather than using the existing approach of replacing the whole lot.
That would be the golden way of course.
Thinking twice about it the proper way to do it would be to u
On Mon, Jan 18, 2010 at 06:45:23PM +, Roger Leigh wrote:
schroot can not (does not) support running dæmons such as exim.
The problem was not running it, but removing it (because it used
dpkg-statoverride with a "custom" group). It was installed via some
dependency chain (about any non-triv
On Mon, Jan 18, 2010 at 05:48:10PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> Bug reassigned from package 'exim4' to 'schroot'.
> Bug #565613 [schroot] exim4: syntax error: unknown group 'Debian-exim' in
&g
reassign 565613 schroot 1.2.3-1+b1
retitle 565613 overwrites customized /etc/passwd and /etc/group
thanks
On Sun, Jan 17, 2010 at 01:50:24PM +0100, Andreas Metzler wrote:
the major question is: What/who removed the Debian-exim group?
I found the culprit: With the default configuration schroot (
On 2010-01-17 Sascha Silbe wrote:
> Package: exim4
> Severity: critical
> Justification: breaks unrelated software
> Reason for marking critical: Until /var/lib/dpkg/statoverride is fixed
> manually (even dpkg-statoverride --remove doesn't work anymore) all package
> management operations fail
Package: exim4
Severity: critical
Justification: breaks unrelated software
Reason for marking critical: Until /var/lib/dpkg/statoverride is fixed manually
(even dpkg-statoverride --remove doesn't work anymore) all package management
operations fail.
Replacing exim4 with nullmailer causes aptit
7 matches
Mail list logo