Le 24/11/2014 20:24, Andrei POPESCU a écrit :
On Lu, 24 nov 14, 09:26:00, Didier Roche wrote:
See my answer on bug #764607, I think the Alias permits us to achieve this,
in a same way we have alternatives. Then, it requires that the target
Wants= though.
This didn't seem to work so well when lx
Processing commands for cont...@bugs.debian.org:
> tags 770734 + moreinfo unreproducible
Bug #770734 [src:systemd] systemd: FTBFS in environment with all packages
rebuilt locally
Added tag(s) unreproducible and moreinfo.
> thanks
Stopping processing here.
Please contact me if you need assistance
Processing commands for cont...@bugs.debian.org:
> severity 770644 important
Bug #770644 [systemd] systemd: systemd is completely unusable after a fatal
signal
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
770644: http
Processing commands for cont...@bugs.debian.org:
> found 770644 215-1
Bug #770644 [systemd] systemd: systemd is completely unusable after a fatal
signal
Marked as found in versions systemd/215-1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
770644: http://bugs
Hi,
Quentin Lefebvre wrote (24 Nov 2014 21:19:56 GMT) :
> So here is the point of view of the developers.
> The upstream patch works provided that "hash=plain" is mentioned in
> /etc/cryptab.
> To summarize:
> - when a user creates a plain dm-crypt device providing a --hash parameter
> along wi
Before adding to this bug, I ran:
systemctl enable rsyslog.service
/etc/init.d/rsyslog start
My understanding is that the workaround for this bug required me to run these
commands. I'm not sure why the upgrade of systemd from 208-8 to 215-5+b1 on 7
October prevented syslog from starting.
On
Package: systemd-sysv
Version: 215-5+b1
Severity: important
At shutdown or reboot time, after X dies, the screen is just black. I see no
updates.
I see no status. No nothing. This was not the case with sysvinit (as each
service was
stopped, status was displayed). Is this normal under sytemd?
On Nov 24, Tomas Pospisek wrote:
> Since there is 'systemd-detect-virt', would it be possible for the systemd
> preinst to check for a LXC system and then to prompt the user with something
> like this? :
We will seriously consider merging such a patch, if somebody will
provide one.
> Theoretica
Hello Marco,
On Mon, 24 Nov 2014, Marco d'Itri wrote:
On Nov 24, Tomas Pospisek wrote:
1. As far as I understand this is a patch for a template used to create a
new jessie LXC VM. Am I thus correct in assuming it's of no use for
the "upgrade a LXC VM from wheezy to jessie"?
Yes, the c
On 24/11/14 21:41, Gerrit Pape wrote:
> Better than (2) would be to make the existence of /etc/inittab still
> essential for jessie, by moving the corresponding code from
> sysvinit-core into the essential init package. What do you think?
If you go this route, I think initscripts might be a bette
On Sat, Oct 25, 2014 at 09:34:50AM +, Gerrit Pape wrote:
> On Wed, Oct 22, 2014 at 09:20:46AM +, Gerrit Pape wrote:
> > On Tue, Oct 21, 2014 at 08:29:54AM -0400, Nikolay Hristov wrote:
> > > Setting up runit (2.1.2-1) ...
> > > grep: /etc/inittab: No such file or directory
> > > grep: /etc/
So here is the point of view of the developers.
The upstream patch works provided that "hash=plain" is mentioned in
/etc/cryptab.
To summarize:
- when a user creates a plain dm-crypt device providing a --hash
parameter along with a key file
- he *should* be aware of the fact that the hash par
On Lu, 24 nov 14, 09:26:00, Didier Roche wrote:
>
> See my answer on bug #764607, I think the Alias permits us to achieve this,
> in a same way we have alternatives. Then, it requires that the target
> Wants= though.
This didn't seem to work so well when lxdm declared
Alias=display-manager.servi
Hi,
On 24/11/2014 16:37, intrigeri wrote :
Quentin Lefebvre wrote (24 Nov 2014 14:35:45 GMT) :
For your information, a patch has been applied upstream.
Here is the link:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93
Congrats!
Can you please try to apply the upstream patch
Processing control commands:
> tag -1 fixed-upstream
Bug #770275 [systemd] nspawn units a bit hard to get working
Added tag(s) fixed-upstream.
--
770275: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770275
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
__
Control: tag -1 fixed-upstream
Hey Joey,
Joey Hess [2014-11-20 2:33 -0400]:
> * /var/lib/container doesn't exist, so the admin will have to make
> the directory in order to put containers where systemd expects to find
> them.
Fixed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=7
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package systemd
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.o
#
# bts-link upstream status pull for source package systemd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #768577 (http://bugs.debian.org/768577)
# Bug title: systemd-cryptsetup handles keyfil
On Nov 24, Tomas Pospisek wrote:
> 1. As far as I understand this is a patch for a template used to create a
>new jessie LXC VM. Am I thus correct in assuming it's of no use for
>the "upgrade a LXC VM from wheezy to jessie"?
Yes, the configuration of existing servers will have to be updat
On Mon, 24 Nov 2014, Antonio Terceiro wrote:
On Mon, Nov 24, 2014 at 07:48:28AM +0100, Tomas Pospisek wrote:
On Mon, 24 Nov 2014, Marco d'Itri wrote:
On Nov 24, Tomas Pospisek wrote:
My first proposed text for the release-notes is below. Please let me
know if you prefer me to submit a prop
Hi Quentin,
Quentin Lefebvre wrote (24 Nov 2014 14:35:45 GMT) :
> For your information, a patch has been applied upstream.
> Here is the link:
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93
Congrats!
Can you please try to apply the upstream patch on top of Debian
unstable's
Hi,
For your information, a patch has been applied upstream.
Here is the link:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93
Cheers,
Quentin
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
h
On Mon, Nov 24, 2014 at 07:48:28AM +0100, Tomas Pospisek wrote:
> On Mon, 24 Nov 2014, Marco d'Itri wrote:
>
> >On Nov 24, Tomas Pospisek wrote:
> >
> >>My first proposed text for the release-notes is below. Please let me
> >>know if you prefer me to submit a proper patch against a SVN checkout o
Here is an updated version of the patch (ensuring we echo a warning if
systemctl enable fails) after discussing with Laurent.
There seems to be one case failing due to the autogenerated gdm3 service
script from the LSB version which is making systemctl enable --force
gdm3 failing, investigatin
> What is the underlying problem you're trying to solve?
That one daemon (namely wd_keepalive) needs to be started when another
daemon (namely watchdog) is stopped. The reason for that is that if the
kernel is configured with NOWAYOUT stopping watchdog will result in a
reset, maybe before shutdown
Le 22/11/2014 21:25, Andrei POPESCU a écrit :
Package: systemd
Version: 215-6
Severity: wishlist
Tags: upstream
Hello,
I think systemd needs a method to deal with multiple providers of the
same service that under usual circumstances (i.e. default configuration)
can't run at the same time, e.g.
Le 22/11/2014 21:28, Andrei POPESCU a écrit :
2b. Each display manager must add a Conflicts=[all other DMs]
You don't really need to maintain a long list of Conflicts (which will
never be kept up to date). I suggested last wek to the gdm maintainers
that we start using the Alias. That enable
27 matches
Mail list logo
