the tracking of the security issues.
Regards
Goffredo
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
(INVCOMMON)
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
;. However this
check is performed only at build time and not at install time. So if the build host is not "/usr
merged" and the target host is "/usr merged", the installation fails.
So In my opinion, it should be re-enable the MD's change.
BR
G.Baroncelli
--
gpg @keyserver
The bug report contains the version "8.30.0-2ghigo1", because this is the one
which I generated when I rebuild the packages rsyslogd with the upstream
commit 4736e53d471ac45024333588fcdf5bce5f8c61b8 (which solve this issue).
Sorry for the confusion.
Package: rsyslog
Version: 8.30.0-2ghigo1
Severity: important
Tags: upstream
When the imjournal module is used, rsyslog doesn't start. This is a know bug
which is fixed by commit 4736e53d471ac45024333588fcdf5bce5f8c61b8.
Note that if the imjournal is used, rsyslog hang and no log is recorded.
According to Florian Weimer [1] I filed a bug against glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=19861
[1] https://sourceware.org/ml/libc-help/2016-03/msg00012.html
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2
00010.html
to me it seems that the real problem is in glibc.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
-Wl,-z,now" from libutempter mosh-server doesn't crash.
- if I remove -lpthread from the linking of "mosh-server", mosh doesn't crash
anymore. Pay attention that -lpthread is not needed, because the -pthread flag
is sufficient.
BR
G.Baroncelli
[*] BTW -lpthread was required by libprotob
I am not sure that libutempter0 is the real culprit, however I find a very
strange behavior:
If I preload libutempter mosh-server didn't crashes. Instead if I run
mosh-server alone, it crashes:
$ ldd /usr/bin/mosh-server
linux-vdso.so.1 (0x7ffce553b000)
libtinfo.so.5 =>
It seems that the problem is related to libutempter0. If commenting the call
in the source of mosh-server, the problem disappear...
Package: mosh
Version: 1.2.5-1.1
Followup-For: Bug #817929
I can confirm that. After a recent update (but I was sure which one) mosh stops
to work.
The problem seems to be in mosh-server which ends with a SIGSEGV after it forks:
$ strace -f mosh-server
execve("/usr/bin/mosh-server",
)
This is the bug report https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
Package: systemd
Version: 225-1
Severity: normal
Tags: patch
systemd assumes that the ESP partition is mounted on /boot. Instead debian
seems to suggest to mount it on /boot/efi/.
(systemd) bootctl relies on this assumption. The user could override this
default via the --path switch, but this
Package: libarchive13
Version: 3.1.2-11ghigo
Severity: normal
Tags: patch
libarchive in linux doesn't support properly the ACL. This is a bug alredy
solved in upstream [1][2].
The problem is that the code which handles ACLs depend by the definition
of the macro ACL_TYPE_NFS4. However in linux
I noticed only now that the library version reported is the 3.1.2-11ghigo. This
is a my mistake. 3.1.2-11ghigo is the library which I rebuild with the patch.
The problem is related to the 3.1.2-10.
BR
G.Baroncelli
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
On 12/11/2014 09:31 PM, Dimitri John Ledkov wrote:
On 10 December 2014 at 19:35, Goffredo Baroncelli kreij...@gmail.com wrote:
Package: btrfs-tools
Version: 3.17-1.1
Severity: wishlist
btrfs-tools has a script for initramfs which load the btrfs module
and does a btrfs device scan.
I
On 12/11/2014 09:37 PM, Dimitri John Ledkov wrote:
On 10 December 2014 at 19:00, Goffredo Baroncelli kreij...@gmail.com wrote:
[...]
But also udev contains a btrfs rules
- 64-btrfs.rules
All rules do the same thing: invoke btrfs device scan. Ok the
udev rules uses an internal builtin
On 12/11/2014 10:40 PM, Dimitri John Ledkov wrote:
On 11 December 2014 at 21:17, Goffredo Baroncelli kreij...@gmail.com wrote:
and the premount script is
there precisely because at the moment udev based discovery is not
sufficient.
I would like to know more about that: in which case udev
Package: btrfs-tools
Version: 3.17-1.1
Severity: important
Hi all,
currently btrfs-tools contains two udev rules:
- 80-btrfs-lvm.rules
- 70-btrfs.rules
But also udev contains a btrfs rules
- 64-btrfs.rules
All rules do the same thing: invoke btrfs device scan. Ok the
udev rules uses an
Package: btrfs-tools
Version: 3.17-1.1
Severity: wishlist
btrfs-tools has a script for initramfs which load the btrfs module
and does a btrfs device scan.
I suggest to replace the btrfs device scan with a udev rule (the
one provided by the package udev, see Bug#772744) which uses
the udev
On 2013-11-30 08:13, Goffredo Baroncelli wrote:
I am trying to send a patch to systemd-devel to split the content of the
systemd sysctl config file in smaller file to simplify the overriding of
the single file.
http://lists.freedesktop.org/archives/systemd-devel/2013-December/015021.html
On 2013-11-29 20:53, Zbigniew Jędrzejewski-Szmek wrote:
Hi Goffredo,
On Thu, Nov 28, 2013 at 10:19:41PM +0100, Goffredo Baroncelli wrote:
Hi Michael,
On 2013-11-28 21:51, Michael Stapelberg wrote:
Hi Goffredo,
Goffredo Baroncelli kreij...@inwind.it writes:
Systemd has as main target
Hi Zbyszek
On 2013-11-28 17:24, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 28, 2013 at 08:50:03AM +0100, Goffredo Baroncelli wrote:
[1] I repeat I am not arguing about the values, I am arguing that a
package which aim to replace the init must change a setting which aren't
related
Hi Zbyszek
On 2013-11-28 20:57, Zbigniew Jędrzejewski-Szmek wrote:
So we're in agreement, except for this last point...
On Thu, Nov 28, 2013 at 07:27:34PM +0100, Goffredo Baroncelli wrote:
This is the point where we have a totally different opinion:
- is job of systemd to set the sysctl
Hi Michael,
On 2013-11-28 21:51, Michael Stapelberg wrote:
Hi Goffredo,
Goffredo Baroncelli kreij...@inwind.it writes:
Systemd has as main target Fedora. Debian is different from Fedora, so
Nope.
systemd is not targeting one distribution as its main target. It is
running on many
HI Michael,
On 2013-11-27 22:57, Michael Stapelberg wrote:
Hi Goffredo,
Goffredo Baroncelli kreij...@inwind.it writes:
As already written I am not complaining about the specific systemd
sysctl values, nor the fact that systemd sets some values during the
boot. I am complaining
On 2013-10-06 01:00, Michael Biebl wrote:
tags 725422 + moreinfo
severity 725422 normal
thanks
Am 05.10.2013 18:27, schrieb Goffredo Baroncelli:
Package: systemd
Version: 204-5
Severity: important
Tags: upstream
Problem description:
After installing the systemd package some sysrq
On 2013-10-06 11:45, Goffredo Baroncelli wrote:
On 2013-10-06 01:00, Michael Biebl wrote:
tags 725422 + moreinfo
severity 725422 normal
thanks
BTW, I am looking a way to change this default without changing this
file. I supposed that adding a file in /etc/sysctl.d with the MY default
On 2013-10-06 11:55, Goffredo Baroncelli wrote:
On 2013-10-06 11:45, Goffredo Baroncelli wrote:
On 2013-10-06 01:00, Michael Biebl wrote:
tags 725422 + moreinfo
severity 725422 normal
thanks
BTW, I am looking a way to change this default without changing this
file. I supposed
Package: systemd
Version: 204-5
Severity: important
Tags: upstream
Problem description:
After installing the systemd package some sysrq keys don't work any more.
Expected behaviour:
The systemd package must not interact with the sysrq key setting
Analysis:
The systemd package contains the file
30 matches
Mail list logo
