143 solve this issue.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
se it. But
in general, being the nvidia driver huge, this creates problem in small (!)
EFI partition.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
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
COMMON) $(INVINCL) $(INVCOMMON)
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
usr merged". 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.Baroncell
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.
Sta
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
t 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
remove "-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 -lpth
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 => /l
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", ["mosh-ser
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 is
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 subj
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 thi
On 12/11/2014 10:40 PM, Dimitri John Ledkov wrote:
> On 11 December 2014 at 21:17, Goffredo Baroncelli wrote:
>>> and the premount script is
>>> there precisely because at the moment udev based discovery is not
>>> sufficient.
>>
>> I would like to know
On 12/11/2014 09:37 PM, Dimitri John Ledkov wrote:
> On 10 December 2014 at 19:00, Goffredo Baroncelli wrote:
[...]
>> But also udev contains a btrfs rules
>>
>> - 64-btrfs.rules
>>
>> All rules do the same thing: invoke "btrfs device scan". Ok the
>
On 12/11/2014 09:31 PM, Dimitri John Ledkov wrote:
> On 10 December 2014 at 19:35, Goffredo Baroncelli wrote:
>> Package: btrfs-tools
>> Version: 3.17-1.1
>> Severity: wishlist
>>
>>
>> btrfs-tools has a script for initramfs which load the btrfs module
>
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 bu
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 inte
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/01
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,
>>>
>>> Goffre
Hi Michael,
On 2013-11-28 21:51, Michael Stapelberg wrote:
> Hi Goffredo,
>
> Goffredo Baroncelli 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
> ru
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
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 ar
HI Michael,
On 2013-11-27 22:57, Michael Stapelberg wrote:
> Hi Goffredo,
>
> Goffredo Baroncelli 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
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 lookin
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
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
>>
>>
>
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
32 matches
Mail list logo
