Processing control commands:
> reassign -1 release-notes
Bug #760947 [systemd] systemd: Does not start consoles configured in
/etc/inittab
Bug reassigned from package 'systemd' to 'release-notes'.
No longer marked as found in versions systemd/208-8.
Ignoring request to alter fixed versions of bug
Control: reassign -1 release-notes
Am 07.06.2015 um 08:32 schrieb Samuel Thibault:
> Michael Biebl, le Sun 07 Jun 2015 01:41:59 +0200, a écrit :
>> /etc/inittab is a sysvinit specific config file, which systemd won't
>> read. This is not going to change.
>>
>> If you have custom changes to /etc/in
systemd_220-5_amd64.changes uploaded successfully to localhost
along with the files:
systemd_220-5.dsc
systemd_220-5.debian.tar.xz
libnss-myhostname_220-5_amd64.deb
libnss-mymachines_220-5_amd64.deb
libpam-systemd_220-5_amd64.deb
libsystemd-daemon-dev_220-5_amd64.deb
libsystemd-dev_22
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 07 Jun 2015 16:52:33 +0200
Source: systemd
Binary: systemd systemd-sysv libpam-systemd libnss-myhostname libnss-mymachines
libsystemd0 libsystemd-dev libsystemd-login-dev libsystemd-daemon-dev
libsystemd-journal-
Your message dated Sun, 07 Jun 2015 16:26:03 +
with message-id
and subject line Bug#787256: fixed in systemd 220-5
has caused the Debian Bug report #787256,
regarding sudo.service:7 Failed to unescape command line, ignoring
to be marked as done.
This means that you claim that the problem has
Your message dated Sun, 07 Jun 2015 16:26:03 +
with message-id
and subject line Bug#787553: fixed in systemd 220-5
has caused the Debian Bug report #787553,
regarding fails to boot with a dracut generated initramfs
to be marked as done.
This means that you claim that the problem has been deal
Your message dated Sun, 07 Jun 2015 16:26:03 +
with message-id
and subject line Bug#787258: fixed in systemd 220-5
has caused the Debian Bug report #787258,
regarding FTBFS on mipsel: test-suite failures
to be marked as done.
This means that you claim that the problem has been dealt with.
If
Hi all,
On 2015-06-03 00:02, Cyril Brulebois wrote:
> Michael Biebl (2015-06-02):
>> Control: block -1 by 782475
>> Am 02.06.2015 um 18:11 schrieb Cyril Brulebois:
>>> libudev1-udeb depends on missing libcap2. I suspect the easiest would be
>>> to drop libcap2 support from the udeb build. An alte
2015-06-07 18:59 GMT+02:00 Christian Kastner :
>> [...]
> Sorry for the delay, I was AFK until just now.
>
> I've prepared a quick upload consisting of only Matthias' patch, minus
> the superfluous d/shlibs.local as discussed in Michael's follow-up to
> the patch.
>
> I do still need a sponsor, tho
Am 07.06.2015 um 19:06 schrieb Matthias Klumpp:
> 2015-06-07 18:59 GMT+02:00 Christian Kastner :
>>> [...]
>> http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc
> Looks fine to me and builds & works fine as well :) - I could sponsor
> the package this evening, if there are no o
Hello Christian,
Christian Kastner (2015-06-07):
> Sorry for the delay, I was AFK until just now.
>
> I've prepared a quick upload consisting of only Matthias' patch, minus
> the superfluous d/shlibs.local as discussed in Michael's follow-up to
> the patch.
>
> I do still need a sponsor, though
Hi again,
On 2015-06-07 23:22, Cyril Brulebois wrote:
> Christian Kastner (2015-06-07):
>> Sorry for the delay, I was AFK until just now.
>>
>> I've prepared a quick upload consisting of only Matthias' patch, minus
>> the superfluous d/shlibs.local as discussed in Michael's follow-up to
>> the pa
Am 07.06.2015 um 23:59 schrieb Christian Kastner:
> On 2015-06-07 23:22, Cyril Brulebois wrote:
>> Christian Kastner (2015-06-07):
>> | @@ -1,4 +1,5 @@
>> | libcap.so.2 libcap2 #MINVER#
>> | + __cap_lookup_name@Base 1:2.24-9
>> | _cap_names@Base 1:2.10
>> | _libcap_strdup@Base 1:2.10
>> More
Hello Christian & Michael,
Michael Biebl (2015-06-08):
> Am 07.06.2015 um 23:59 schrieb Christian Kastner:
> > On 2015-06-07 23:22, Cyril Brulebois wrote:
> >> Christian Kastner (2015-06-07):
> >> | @@ -1,4 +1,5 @@
> >> | libcap.so.2 libcap2 #MINVER#
> >> | + __cap_lookup_name@Base 1:2.24-9
> >
#include
Christian Kastner (2015-06-07):
> I looked into this and I can reproduce the issue. In one of the
> Makefiles, there's a test for the presence of gperf(1), and if so,
> stuff happens, and the above symbol eventually gets added.
Yeah, and that tool is indeed present in the devel chroot
Package: systemd
Version: 220-4
Severity: important
Dear maintainer.
For a few days now each time the computer boots it forces a file system
check on two of my disks.
Here is the relevant journalctl entry :
Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
as /devices/platform/i8042/s
16 matches
Mail list logo
