from:"Goffredo Baroncelli"

Bug#981176: Rename the doas package as opendoas package

2021-01-29 Thread Goffredo Baroncelli


opendoas is a derived project from the openbsd doas project. The differences 
are quite important from a security point of view: it comes to me the pam and 
persistent support.

Several other projects are derived from the original doas, like:
- https://github.com/multiplexd/doas
- https://github.com/slicer69/doas

Each one has a different implementation either of pam or persistent support.

In order to reduce the confusion, I think that it does make sense to rename the 
doas debian package in opendoas, to highlight the project from which the 
package is built.

This would help also 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

Bug#953537: Info received (xfsdump fails to install in /usr merged system.)

2020-03-13 Thread Goffredo Baroncelli


On 3/13/20 1:54 PM, Debian Bug Tracking System wrote:


This a possible solution

diff -Naur xfsdump-3.1.9/debian/xfsdump.postinst 
xfsdump-3.1.9+nmu1/debian/xfsdump.postinst
--- xfsdump-3.1.9/debian/xfsdump.postinst   1970-01-01 01:00:00.0 
+0100
+++ xfsdump-3.1.9+nmu1/debian/xfsdump.postinst  2020-03-13 13:54:21.0 
+0100
@@ -0,0 +1,12 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = 'configure' ]; then
+  for file in xfsdump xfsrestore; do
+if [ ! -e /usr/sbin/$file ]; then
+  ln -s /sbin/$file /usr/sbin/$file
+fi
+  done
+fi
+
+#DEBHELPER#
diff -Naur xfsdump-3.1.9/debian/xfsdump.postrm 
xfsdump-3.1.9+nmu1/debian/xfsdump.postrm
--- xfsdump-3.1.9/debian/xfsdump.postrm 1970-01-01 01:00:00.0 +0100
+++ xfsdump-3.1.9+nmu1/debian/xfsdump.postrm2020-03-13 13:54:41.0 
+0100
@@ -0,0 +1,12 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = 'remove' ]; then
+  for file in xfsdump xfsrestore; do
+if [ -L /usr/sbin/$file ]; then
+  rm /usr/sbin/$file
+fi
+  done
+fi
+
+#DEBHELPER#
diff -Naur xfsdump-3.1.9/dump/Makefile xfsdump-3.1.9+nmu1/dump/Makefile
--- xfsdump-3.1.9/dump/Makefile 2020-01-31 18:30:58.0 +0100
+++ xfsdump-3.1.9+nmu1/dump/Makefile2020-03-13 13:50:57.0 +0100
@@ -100,9 +100,6 @@
$(INSTALL) -m 755 -d $(PKG_ROOT_SBIN_DIR)
$(LTINSTALL) -m 755 $(LTCOMMAND) $(PKG_ROOT_SBIN_DIR)
$(INSTALL) -m 755 -d $(PKG_SBIN_DIR)
-   # skip symlink when /sbin is alread symlinked to /usr/sbin, like on 
Fedora
-   test $(PKG_ROOT_SBIN_DIR) -ef $(PKG_SBIN_DIR) || \
-   $(INSTALL) -S $(PKG_ROOT_SBIN_DIR)/$(LTCOMMAND) 
$(PKG_SBIN_DIR)/$(LTCOMMAND)
 install-dev:
 
 .dep: $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON)

diff -Naur xfsdump-3.1.9/restore/Makefile xfsdump-3.1.9+nmu1/restore/Makefile
--- xfsdump-3.1.9/restore/Makefile  2020-01-31 18:30:58.0 +0100
+++ xfsdump-3.1.9+nmu1/restore/Makefile 2020-03-13 13:51:11.0 +0100
@@ -115,8 +115,6 @@
$(LTINSTALL) -m 755 $(LTCOMMAND) $(PKG_ROOT_SBIN_DIR)
$(INSTALL) -m 755 -d $(PKG_SBIN_DIR)
# skip symlink when /sbin is alread symlinked to /usr/sbin, like on 
Fedora
-   test $(PKG_ROOT_SBIN_DIR) -ef $(PKG_SBIN_DIR) || \
-   $(INSTALL) -S $(PKG_ROOT_SBIN_DIR)/$(LTCOMMAND) 
$(PKG_SBIN_DIR)/$(LTCOMMAND)
 install-dev:
 
 .dep: $(COMMINCL) $(COMMON) $(INVINCL) $(INVCOMMON)


--
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Bug#953537: xfsdump fails to install in /usr merged system.

2020-03-13 Thread Goffredo Baroncelli


This bug was already addressed in the past by Marco d'Itri. Now it reappears. 
See the debian change log

[...]
xfsdump (3.1.6+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Create in postinst the xfsdump and xfsrestore compatibility symlinks.
This is needed to support merged /usr systems (closes: #767926)

 -- Marco d'Itri   Thu, 07 Jan 2016 22:44:28 +0100
[...]

The problem is that the original xfsdump Makefile(s) (both the one under dump/ 
and the one under restore/) install the binary under /sbin and create a symlink 
to the binary under /usr/sbin. Of course this doesn't work when the system has 
/[s]bin and /usr/[s]bin merged.

Looking at the past packages (3.1.6+nm1), the symlinking where dropped from the 
Makefile, and where added in the *.{postinst,postrm} hooks.

I have to point out that the actual Makefile checks if the system is "/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.Baroncelli

--
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Bug#882261: Acknowledgement (rsyslog: imjournal doesn't work)

2017-11-20 Thread Goffredo Baroncelli

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.

Bug#882261: rsyslog: imjournal doesn't work

2017-11-20 Thread Goffredo Baroncelli

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.

Starting manually, I got the following error messages

$ sudo rsyslogd
rsyslogd: sd_journal_next() failed: 'No such file or directory' [v8.30.0]

Depending by how systemd-journald is configured, this could means no log at 
all. This is the reason of the severity (important), even tough I have to admit 
that this is an uncommon configuration, so the occurence is very low.

BR
G.Baroncelli 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.13.7 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.51
ii  libc62.24-17
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.7-1
ii  liblogging-stdlog0   1.0.6-1
ii  liblognorm5  2.0.3-1
ii  libsystemd0  235-3
ii  libuuid1 2.30.2-0.1
ii  lsb-base 9.20170808
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages rsyslog recommends:
ii  logrotate  3.11.0-0.1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/rsyslog.conf changed:
module(load="imjournal" PersistStateInterval="100"
   StateFile="/var/log/rsyslog-imjournal.state") #load imjournal module
module(load="mmjsonparse") #load mmjsonparse module for structured logs
template(name="CEETemplate" type="string" 
string="%timegenerated:::date-rfc3339% %HOSTNAME% %syslogtag% @cee: 
%$!all-json%\n" ) #template for messages
action(type="mmjsonparse")
action(type="omfile" file="/var/log/cee.log" template="CEETemplate") 
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$WorkDirectory /var/spool/rsyslog
$IncludeConfig /etc/rsyslog.d/*.conf
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none  -/var/log/syslog
daemon.*-/var/log/daemon.log
kern.*  -/var/log/kern.log
lpr.*   -/var/log/lpr.log
mail.*  -/var/log/mail.log
user.*  -/var/log/user.log
mail.info   -/var/log/mail.info
mail.warn   -/var/log/mail.warn
mail.err/var/log/mail.err
news.crit   /var/log/news/news.crit
news.err/var/log/news/news.err
news.notice -/var/log/news/news.notice
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none  -/var/log/messages
*.emerg :omusrmsg:*
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/dev/xconsole
*.* /dev/tty12


-- no debconf information

Bug#817929: Bug in glibc

2016-03-23 Thread Goffredo Baroncelli

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 0EDA 9B37 8B82 E0B5

Bug#817929: mosh fails to connect, giving a UDP error

2016-03-22 Thread Goffredo Baroncelli

On Mon, 21 Mar 2016 19:23:54 -0400 Matthew Gabeler-Lee <chee...@fastcat.org> 
wrote:
> Package: mosh
> Version: 1.2.5-1.1
> Followup-For: Bug #817929
> 
> Looks like upstream has a patch for this:
> 
> https://github.com/mobile-shell/mosh/pull/732/commits/a47917b97606a03f6bbf0cafd1fcd495b0229790
> 
> Though it looks like that's a hack and they really want this fixed in
> protobuf:
> 
> https://github.com/google/protobuf/pull/1333
> 
> Which also has a patch.

Please give a look to

https://sourceware.org/ml/libc-help/2016-03/msg00010.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

Bug#817929: Minimal test case

2016-03-19 Thread Goffredo Baroncelli

Ok, I was able to track down a __very__ minimal test case: the problem seems to 
be a "strange" interaction between the linker flag used during the creation of 
libutemper, and the inclusion of -lpthread[*] during the linking of mosh-server.
It is not a problem related to mosh and/or libutempter. In fact I was able to 
create a test without involving these two.

$ cat boom.c
extern void dofork();

int main() {
dofork();
}

$ cat dofork.c 
#include 

void dofork() {
fork();
}

$ gcc -shared -Wl,-z,now -o libdofork.so dofork.o
$ gcc -o boom boom.c -lpthread -L$(pwd) -ldofork
$ LD_LIBRARY_PATH=$(pwd) ldd ./boom linux-vdso.so.1 (0x7ffe817dc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f16b38ed000)
libdofork.so => /home/ghigo/mosh/libdofork.so (0x7f16b36ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f16b3347000)
/lib64/ld-linux-x86-64.so.2 (0x562eba12a000)
$ LD_LIBRARY_PATH=$(pwd) ./boom
Segmentation fault

The key points are:
- put a fork in a shared library
- link the shared library with "-Wl,-z,now"
- compile a program with libpthread and the library above (note: libpthread is 
not needed)
- put libpthread before the library above

Then I got a crash. The test was performed on a debian machine with libc6 2.22. 
Even on a fedora F23 (=libc-2.22) I got the crash.

If I performed the same test on a debian machine with libc6 2.19 instead of 
libc6 2.22, the crash doesn't happen.
If I remove "-lpthread" or "-Wl,-z,now" flag, the crash doesn't happen.
If I put the fork() in the main(), the crash doesn't happen.

My (limitated) knowledge doesn't suggest me any valid reason about why the 
crashes. However 
- if I 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 -lpthread was required by libprotobuf

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Bug#817929: mosh and libutempter

2016-03-15 Thread Goffredo Baroncelli

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 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f8966678000)
libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 
(0x7f896634e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f896613)
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 
(0x7f8965ec7000)
libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 
(0x7f8965a64000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f896586)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8965645000)
--> libutempter.so.0 => /usr/lib/x86_64-linux-gnu/libutempter.so.0 
(0x7f8965442000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f89650be000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8964dc)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8964baa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8964805000)
/lib64/ld-linux-x86-64.so.2 (0x561792d06000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8964601000)


$ /usr/bin/mosh-server 

In dmesg I got "mosh-server[8320]: segfault at 0 ip"


Instead if I do

$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libutempter.so.0 /usr/bin/mosh-server

mosh-server didn't crash...

I am inclined to think that preloading the library I change the library 
arrangement in memory; this could hide/show some wrong memory access.

Any idea how debug this ?

G.Baroncelli

Bug#817929: libutempter related problem ?

2016-03-12 Thread Goffredo Baroncelli

It seems that the problem is related  to libutempter0. If commenting the call 
in the source of mosh-server, the problem disappear...

Bug#817929: mosh fails to connect, giving a UDP error

2016-03-11 Thread Goffredo Baroncelli

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-server"], [/* 23 vars */]) = 0
brk(NULL)   = 0x5614e69fc000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9e62de8000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=191871, ...}) = 0
mmap(NULL, 191871, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9e62db9000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
[...]
[...]
mprotect(0x7f9e600e7000, 4096, PROT_READ) = 0
mprotect(0x7f9e602f9000, 4096, PROT_READ) = 0
munmap(0x7f9e62d81000, 191871)  = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 6
lseek(6, 0, SEEK_CUR)   = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=1105, ...}) = 0
mmap(NULL, 1105, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9e62de6000
lseek(6, 1105, SEEK_SET)= 1105
munmap(0x7f9e62de6000, 1105)= 0
close(6)= 0
ioctl(5, TIOCSPTLCK, [0])   = 0
ioctl(5, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(5, TIOCGPTN, [7]) = 0
stat("/dev/pts/7", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
open("/dev/pts/7", O_RDWR|O_NOCTTY) = 6
ioctl(6, TIOCSWINSZ, {ws_row=45, ws_col=115, ws_xpixel=0, ws_ypixel=0}) = 0
clone(strace: Process 18446 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f9e62db1a10) = 18446
[pid 18446] set_robust_list(0x7f9e62db1a20, 24) = 0
[pid 18445] close(6 
[pid 18446] close(5 
[pid 18445] <... close resumed> )   = 0
[pid 18446] <... close resumed> )   = 0
[pid 18445] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 
0x7f9e62468d30},  
[pid 18446] setsid( 
[pid 18445] <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) = 0
[pid 18446] <... setsid resumed> )  = 18446
[pid 18445] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
[pid 18446] ioctl(6, TIOCSCTTY, 0)  = 0
[pid 18446] dup2(6, 0)  = 0
[pid 18446] dup2(6, 1)  = 1
[pid 18446] dup2(6, 2)  = 2
[pid 18446] close(6)= 0
[pid 18446] rt_sigaction(SIGHUP, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 
0x7f9e62468d30}, NULL, 8) = 0
[pid 18446] --- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
[pid 18445] +++ killed by SIGSEGV +++
+++ killed by SIGHUP +++


Enclose you can find the full strace.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg1.18.4
ii  libc6   2.22-2
ii  libgcc1 1:6-20160220-1
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2 1.0.2g-1
ii  libstdc++6  6-20160220-1
ii  libtinfo5   6.0+20160213-1
ii  libutempter01.1.6-3
ii  openssh-client  1:7.2p2-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  perl-base [libio-socket-ip-perl]  5.22.1-8

mosh suggests no packages.

-- no debconf information
ming and intelligent local echo
ghigo@venice:~$ strace -f mosh-server 
execve("/usr/bin/mosh-server", ["mosh-server"], [/* 23 vars */]) = 0
brk(NULL)   = 0x5614e69fc000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9e62de8000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=191871, ...}) = 0
mmap(NULL, 191871, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9e62db9000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\320\0\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0644, st_size=171752, ...}) = 0
mmap(NULL, 2268768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f9e6299f000
mprotect(0x7f9e629c5000, 2093056, PROT_NONE) = 0
mmap(0x7f9e62bc4000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f9e62bc4000
close(3)= 0

Bug#737305: libvte9: please include scroll_region_updates.patch from vte3 package

2016-03-02 Thread Goffredo Baroncelli

I had the same problem which was reported in bug #684445 (unreliable refresh 
when scrolling in mosh), which in turn forward to this bugreport. 
This patch 


https://git.gnome.org/browse/vte/commit/?id=88e8e89560a62d0981ce2b18974a230d0a07dbdd

solved this issue, so please apply.


Arch linux also uses the same patch

https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/vte

(here the bug https://bugs.archlinux.org/task/37419)



Ubuntu uses the same patch from vte  1:0.28.1-1ubuntu1 
(https://launchpad.net/ubuntu/+source/vte/1:0.28.1-1ubuntu1)

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

Bug#798083: systemd: Systemd assumes that ESP is mounted in /boot

2015-09-05 Thread Goffredo Baroncelli

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 annoing.

The patch below adds a check: if the /boot/efi/EFI directory exists, bootctl 
assumes that the ESP is mounted on /boot/efi, otherwise /boot.
Anyway the user can still override the default using the --path switch.

I proposed the patch upstream [1] but it was rejected becuase the systemd
developers want to support only mounting ESP on /boot.

BR
G.Baroncelli

[1] https://github.com/systemd/systemd/pull/1124


diff --git a/man/bootctl.xml b/man/bootctl.xml
index 63ad939..0a96aae 100644
--- a/man/bootctl.xml
+++ b/man/bootctl.xml
@@ -102,7 +102,7 @@
   
   
 --path
-Path to the EFI system partition. The default is 
/boot.
+Path to the EFI system partition. By default bootctl 
uses /boot/efi (if ESP is mounted here) or /boot.
   
 
   
diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c
index ac1711b..319994e 100644
--- a/src/boot/bootctl.c
+++ b/src/boot/bootctl.c
@@ -936,7 +936,7 @@ static int help(void) {
 return 0;
 }
 
-static const char *arg_path = "/boot";
+static const char *arg_path = NULL;
 static bool arg_touch_variables = true;
 
 static int parse_argv(int argc, char *argv[]) {
@@ -996,6 +996,18 @@ static void read_loader_efi_var(const char *name, char 
**var) {
 log_warning_errno(r, "Failed to read EFI variable %s: %m", 
name);
 }
 
+static void init_arg_path(void) {
+struct stat st;
+
+if (stat("/boot/efi/EFI", ) == 0 && (st.st_mode & S_IFMT) == 
S_IFDIR) {
+/* Suse, debian, ubuntu, gentoo, fedora */
+arg_path = "/boot/efi";
+} else {
+/* arch */
+arg_path = "/boot";
+}
+}
+
 static int bootctl_main(int argc, char*argv[]) {
 enum action {
 ACTION_STATUS,
@@ -1036,6 +1048,9 @@ static int bootctl_main(int argc, char*argv[]) {
 if (geteuid() != 0)
 return log_error_errno(EPERM, "Need to be root.");
 
+if (arg_path == NULL)
+init_arg_path();
+
 r = verify_esp(arg_path, , , , );
 if (r == -ENODEV && !arg_path)
 log_notice("You might want to use --path= to indicate the path 
to your ESP, in case it is not mounted on /boot.");


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.9.2-3
ii  libaudit1   1:2.4.4-1
ii  libblkid1   2.26.2-9
ii  libc6   2.19-19
ii  libcap2 1:2.24-11
ii  libcap2-bin 1:2.24-11
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.26.2-9
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 225-1
ii  mount   2.26.2-9
ii  sysv-rc 2.88dsf-59.2
ii  udev225-1
ii  util-linux  2.26.2-9

Versions of packages systemd recommends:
ii  dbus1.8.20-1
ii  libpam-systemd  225-1

Versions of packages systemd suggests:
ii  systemd-container  225-1
pn  systemd-ui 

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]

-- no debconf information


bootctl-ESP.diff
Description: inode/empty

Bug#778253: libarchive13: archive_read_disk_entry_from_file() and archive_write_disk_set_acls() don't preserv ACL.

2015-02-12 Thread Goffredo Baroncelli

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 this macro is not defined.

During the packaging build, dpkg-shlibdeps warns abou the fact the the acl 
library is unused:
---
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/libarchive13/usr/lib/x86_64-linux-gnu/libarchive.so.13.1.2 was not 
linked against libacl.so.1 (it uses none of the library's symbols)
---

In upstream the problem is solved by the patch [2]. Fedora
solved this issue cherry-picking the same patch [4].

I made a new version the libarchive package: I put the commit [2] in
debian/patches/, I update debian/patches/series adding the new patch, 
and finally I updated the debian/changelog file. The package compiled and
now my tests showed ACL seems supported.

BR
G.Baroncelli


[1] https://code.google.com/p/libarchive/issues/detail?id=329
[2] See commit b45c3ae1825c8cedc7cde2972a04974f73b08315
[3] https://bugzilla.redhat.com/show_bug.cgi?id=993048
[4] 
http://pkgs.fedoraproject.org/cgit/libarchive.git/commit/?id=da58d4e8afce6acca54475be528f6b948aa2951a

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 3.18.5 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libarchive13 depends on:
ii  libacl12.2.52-2
ii  libattr1   1:2.4.47-2
ii  libbz2-1.0 1.0.6-7+b2
ii  libc6  2.19-15
ii  liblzma5   5.1.1alpha+20120614-2+b3
ii  liblzo2-2  2.08-1.2
ii  libnettle4 2.7.1-5
ii  libxml22.9.2+dfsg1-3
ii  multiarch-support  2.19-15
ii  zlib1g 1:1.2.8.dfsg-2+b1

libarchive13 recommends no packages.

Versions of packages libarchive13 suggests:
pn  lrzip  none

-- no debconf information
commit b45c3ae1825c8cedc7cde2972a04974f73b08315
Author: Tim Kientzle kient...@acm.org
Date:   Sat Jan 4 21:46:57 2014 -0800

Issue #329: https://code.google.com/p/libarchive/issues/detail?id=329

Fix POSIX.1e draft ACL handling on Linux systems that lack NFSv4 ACL libraries.

diff --git a/libarchive/archive_read_disk_entry_from_file.c b/libarchive/archive_read_disk_entry_from_file.c
index e984aaa..e81cbec 100644
--- a/libarchive/archive_read_disk_entry_from_file.c
+++ b/libarchive/archive_read_disk_entry_from_file.c
@@ -399,7 +399,7 @@ setup_mac_metadata(struct archive_read_disk *a,
 #endif
 
 
-#if defined(HAVE_POSIX_ACL)  defined(ACL_TYPE_NFS4)
+#ifdef HAVE_POSIX_ACL
 static int translate_acl(struct archive_read_disk *a,
 struct archive_entry *entry, acl_t acl, int archive_entry_acl_type);
 
@@ -419,6 +419,7 @@ setup_acls(struct archive_read_disk *a,
 
 	archive_entry_acl_clear(entry);
 
+#ifdef ACL_TYPE_NFS4
 	/* Try NFS4 ACL first. */
 	if (*fd = 0)
 		acl = acl_get_fd(*fd);
@@ -447,6 +448,7 @@ setup_acls(struct archive_read_disk *a,
 		acl_free(acl);
 		return (ARCHIVE_OK);
 	}
+#endif
 
 	/* Retrieve access ACL from file. */
 	if (*fd = 0)
@@ -492,6 +494,7 @@ static struct {
 {ARCHIVE_ENTRY_ACL_EXECUTE, ACL_EXECUTE},
 {ARCHIVE_ENTRY_ACL_WRITE, ACL_WRITE},
 {ARCHIVE_ENTRY_ACL_READ, ACL_READ},
+#ifdef ACL_TYPE_NFS4
 {ARCHIVE_ENTRY_ACL_READ_DATA, ACL_READ_DATA},
 {ARCHIVE_ENTRY_ACL_LIST_DIRECTORY, ACL_LIST_DIRECTORY},
 {ARCHIVE_ENTRY_ACL_WRITE_DATA, ACL_WRITE_DATA},
@@ -508,8 +511,10 @@ static struct {
 {ARCHIVE_ENTRY_ACL_WRITE_ACL, ACL_WRITE_ACL},
 {ARCHIVE_ENTRY_ACL_WRITE_OWNER, ACL_WRITE_OWNER},
 {ARCHIVE_ENTRY_ACL_SYNCHRONIZE, ACL_SYNCHRONIZE}
+#endif
 };
 
+#ifdef ACL_TYPE_NFS4
 static struct {
 int archive_inherit;
 int platform_inherit;
@@ -519,21 +524,25 @@ static struct {
 	{ARCHIVE_ENTRY_ACL_ENTRY_NO_PROPAGATE_INHERIT, ACL_ENTRY_NO_PROPAGATE_INHERIT},
 	{ARCHIVE_ENTRY_ACL_ENTRY_INHERIT_ONLY, ACL_ENTRY_INHERIT_ONLY}
 };
-
+#endif
 static int
 translate_acl(struct archive_read_disk *a,
 struct archive_entry *entry, acl_t acl, int default_entry_acl_type)
 {
 	acl_tag_t	 acl_tag;
+#ifdef ACL_TYPE_NFS4
 	acl_entry_type_t acl_type;
 	acl_flagset_t	 acl_flagset;
+	int brand, r;
+#endif
 	acl_entry_t	 acl_entry;
 	acl_permset_t	 acl_permset;
-	int		 brand, i, r, entry_acl_type;
+	int		 i, entry_acl_type;
 	int		 s, ae_id, ae_tag, ae_perm;
 	const char	*ae_name;
 
 
+#ifdef ACL_TYPE_NFS4
 	// FreeBSD brands ACLs as POSIX.1e or NFSv4
 	// Make sure the brand on this ACL is consistent
 	// with the default_entry_acl_type bits provided.
@@ -560,6 +569,7 @@ translate_acl(struct archive_read_disk *a,
 		return ARCHIVE_FAILED;
 		break;
 	}
+#endif
 
 
 	s = acl_get_entry(acl,

Bug#778253: Library version

2015-02-12 Thread Goffredo Baroncelli

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 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

2014-12-11 Thread Goffredo Baroncelli

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 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 builtin method.
 Because the module may be inserted after that some devices appeared,
 after the module insert,we have to be do a udevadm trigger -s block
 to redoing a device rescan for btrfs.

 
 I disagree, udev in initramfs is optional 

If udev is optional in initramfs, my request has to be rejected.

 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 based
discovery is not sufficient ? Or are you referring about the
fact that udev is not mandatory in initramfs.

[...]

BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules

2014-12-11 Thread Goffredo Baroncelli

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, but the results is the same
 of the first two rules.

 
 64-btrfs.rules does not call scan, it marks btrfs devices as ready
 only. These are not equivalent.

It does a BTRFS_IOC_DEVICES_READY ioctl (see udev-builtin-btrfs.c), 
which, despite its name, *registers* the passed device *and checks* if 
the number of registered device is sufficient. From fs/btrfs/super.c

[...]
/*
 * used by btrfsctl to scan devices when no FS is mounted
 */
static long btrfs_control_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
[...]
switch (cmd) {
case BTRFS_IOC_SCAN_DEV:
ret = btrfs_scan_one_device(vol-name, FMODE_READ,
btrfs_fs_type, fs_devices);
break;
case BTRFS_IOC_DEVICES_READY:
ret = btrfs_scan_one_device(vol-name, FMODE_READ,
btrfs_fs_type, fs_devices);
if (ret)
break;
ret = !(fs_devices-num_devices == fs_devices-total_devices);
break;
}


As you can see BTRFS_IOC_DEVICES_READY acts ALSO as BTRFS_IOC_SCAN_DEV.
(Yes, the name is very confusing, so only looking at the code this thing 
is clear)


 
 I am asking to remove the btrfs-tools rules (80-... and 70-...)
 because the udev rule is sufficient and always present.

 
 All three do different things, under different conditions and are not
 equivalent.

The 64-btrfs.rules is able to superseed the two btrfs-tools package rules 
(80-...
and 70-...). So it is not true that these rules do different thing.


The 80-btrfs-lvm.rules and 70-btrfs.rules appeared before the 64-btrfs.rules 
(March 2012 vs September 2012). This explain the redundancy.

BTW, ironically I was one of the first to suggest to put btrfs device scan in 
a btrfs rule (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/5374)

 
 As confirmation I checked fedora, and there is only one
 btrfs rule, the udev one.

 
 Fedora does not use initramfs-tools, but dracut which incidentally
 ships a udev rule to call btrfs device scan. 

I checked a fedora initramfs and I was unable to find this rule (except
the 64-btrfs.rules)

I am referring the Fedora case to support my request to leave
only 64-btrfs.rules: it is sufficient to cover all the cases. Otherwise
we could drop the 64-btrfs.rules and leave the 70-... and 80-... But
because these are less generic and Debian specific I don't see a valid reason
for that.
64-btrfs.rules is also more efficient because it calls a built-in command and
not an external one.

 Thus even fedora has an
 extra udev rule to call btrfs scan.

No, it has only the 64-btrfs.rules. I re-checked now a fedora-20 initramfs (
initramfs-3.17.4-200.fc20.x86_64.img) and:

- I was able to find the btrfs tools
- I found /lib/udev/rules/64-btrfs.rules (which is the same shipped by
the debian udev package)
- I didn't find any btrfs dev scan invocation.

 
 Do you have a bug with current package? If yes, please describe it,
 otherwise I will be closing this bug report as won't fix.

the problem tha I found was that we have three udev rules, when only one 
is sufficient; I am suggesting to adopt the rule shipped with udev.
If you think that this is not a bug, please consider it as wishlist

BTW, I noticed that the debian rules do the insmod the btrfs module. But this 
should be not necessary anymore. Udev is in charge to create the 
/dev/btrfs-control
device. Any access to this device name starts the insmod of the btrfs module.
(see https://lkml.org/lkml/2010/5/21/134)

 
 Regards,
 
 Dimitri.
 
BR
Goffredo

 
 BR
 G.Baroncelli


 -- System Information:
 Debian Release: 8.0
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)

 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages btrfs-tools depends on:
 ii  e2fslibs1.42.12-1
 ii  libblkid1   2.25.2-3
 ii  libc6   2.19-13
 ii  libcomerr2  1.42.12-1
 ii  liblzo2-2   2.08-1
 ii  libuuid12.25.2-3
 ii  zlib1g  1:1.2.8.dfsg-2+b1

 btrfs-tools recommends no packages.

 btrfs-tools suggests no packages.

 -- no debconf information
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

2014-12-11 Thread Goffredo Baroncelli

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 based
 discovery is not sufficient ? Or are you referring about the
 fact that udev is not mandatory in initramfs.

 
 mosty yes, refereing to the fact that udev is not mandatory in the
 Debian's initramfs. There is also ongoing bug stating that udev based
 discovery is not sufficient in the initramfsless system, i have not
 investigated it completely.

I read something about that. The report stated that btrfs didn't honor the
device=/dev/disk mount options; In this case would be impossible to
mount a multi-device filesystem.
But I didn't understand the reason
 
Goffredo

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules

2014-12-10 Thread Goffredo Baroncelli

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 internal builtin, but the results is the same
of the first two rules.

I am asking to remove the btrfs-tools rules (80-... and 70-...)
because the udev rule is sufficient and always present.

As confirmation I checked fedora, and there is only one
btrfs rule, the udev one.

BR
G.Baroncelli


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages btrfs-tools depends on:
ii  e2fslibs1.42.12-1
ii  libblkid1   2.25.2-3
ii  libc6   2.19-13
ii  libcomerr2  1.42.12-1
ii  liblzo2-2   2.08-1
ii  libuuid12.25.2-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-tools recommends no packages.

btrfs-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

2014-12-10 Thread Goffredo Baroncelli

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 builtin method.
Because the module may be inserted after that some devices appeared,
after the module insert,we have to be do a udevadm trigger -s block
to redoing a device rescan for btrfs.

The goal of this change is to armonize how the btrfs device scan is
done in intramfs to after the initramfs

Below two patch to highlight this change.

BR
G.Baroncelli

--- /usr/share/initramfs-tools/scripts/local-premount/btrfs 2014-11-22 
15:01:04.0 +0100
+++ usr/share/initramfs-tools/scripts/local-premount/btrfs  2014-12-10 
20:31:31.289746904 +0100
@@ -19,5 +19,5 @@
 if [ -x /sbin/btrfs ]
 then
modprobe btrfs
-   /sbin/btrfs device scan 2 /dev/null
+   udevadm trigger -s block
 fi


--- /usr/share/initramfs-tools/hooks/btrfs  2014-11-22 15:01:04.0 
+0100
+++ usr/share/initramfs-tools/hooks/btrfs   2014-12-10 20:34:07.181751787 
+0100
@@ -26,4 +26,13 @@
then
copy_exec /sbin/fsck.btrfs /sbin
fi
+
+   mkdir -p $DESTDIR/lib/udev/rules.d/
+   for rules in 64-btrfs.rules; do
+ if   [ -e /etc/udev/rules.d/$rules ]; then
+   cp -p /etc/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
+ elif [ -e /lib/udev/rules.d/$rules ]; then
+   cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
+ fi
+   done
 fi



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages btrfs-tools depends on:
ii  e2fslibs1.42.12-1
ii  libblkid1   2.25.2-3
ii  libc6   2.19-13
ii  libcomerr2  1.42.12-1
ii  liblzo2-2   2.08-1
ii  libuuid12.25.2-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-tools recommends no packages.

btrfs-tools suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16

2013-12-02 Thread Goffredo Baroncelli

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
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16

2013-11-29 Thread Goffredo Baroncelli

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 Fedora. Debian is different from Fedora, so
 Nope.

 systemd is not targeting one distribution as its main target. It is
 running on many distributions, with no particular focus on any single
 one of them.

 Let me rephrase this sentence: systemd is not sensible to the debian
 requirements; otherwise there would not be the problems to support the
 other debian kernels (like hurd and bsd).
 Even if this were true, this bug report is not about hurd or bsd.
 Since this is a bug report, let me ask again: is there anything to fix
 with the sysctl stuff?

As reported in my first report [1]:

 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


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.

Worse, the workaround which I found [2] will be nullified with the new
systemd versions because it is changing the processing order of the
sysctl files configuration..


IMHO The big problem is that there is a sysctl setting as side effect
of systemd. It would be a debian setting.

Thanks in advance for your work (packaging, testing, talking with the
bug highlighter :-) ).

BR
G.Baroncelli


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725422#29
 
 Zbyszek
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

2013-11-28 Thread Goffredo Baroncelli

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 to the package functionality.
 Hi Goffredo,
 
 upstream value for the sysrq setting was chosen as a safe default.
 If you thing that the default should be changed, it is definitely
 reasonable to discuss it upstream on systemd-de...@l.fd.o.

I was unable to find the discussion where these safe default was
decided, so I don't know the rationale behind them; this seems to me a
debate like ctrl-alt-backspace to kill X: a lot of people have
different opinion about the meaning of safe default. Anyway I am not
complaining about the systemd safe values, even I have a different
opinion.

 The mechanism to set the default is unlikely to change though.
 Modulo the bugs with ordering that Michael pointed out, this
 mechanism is nice and clean, and provides a safe way for the
 administrator to locally override settings.

Let me clear: I think that *how* systemd set the sysctl values *are the
right one* (even tough they changed behaviour without regard the
backward compatibility)

 Also, this is a basic system setting, where it makes sense to change
 the kernel default by default, so it is natural that systemd
 does that. The goal of the systemd project is to take care of the
 basic system setup.

This is the point where we have a totally different opinion:
- is job of systemd to set the sysctl values ? Yes.
- is job of systemd decide *which values* have to be set ? IMHO no. This
is a distribution responsibility. And I think that a distribution should
not accept the systemd defaults, but should provide the own ones.

 Zbyszek

BR
Goffredo


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

2013-11-28 Thread Goffredo Baroncelli

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 values ? Yes.
 - is job of systemd decide *which values* have to be set ? IMHO no. This
 is a distribution responsibility. And I think that a distribution should
 not accept the systemd defaults, but should provide the own ones.

 Why would Debian's defaults differ from any other general purpose
 distro? 
Good question. But let me to rephrase this sentence: why change the
default (== the one previous systemd) Debian value ?

- before systemd, the value of kernel.syrq was 1
- after systemd, the value of kernel.syrq was 16

I think that it should be systemd (or its packager) to justify the gain
to change these defaults.
If it was done, please point me a link, and excuse me for the disturb.

 If you think Debian should do something different than the
 upstream default of '16', then most probably upstream should do so too.

Systemd has as main target Fedora. Debian is different from Fedora, so
may be that different defaults make sense; anyway I am working on a
patch for systemd: basically I want to split the sysctl default in more
files to simplify a possible override.

 
 Zbyszek
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

2013-11-28 Thread Goffredo Baroncelli

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 distributions, with no particular focus on any single
 one of them.

Let me rephrase this sentence: systemd is not sensible to the debian
requirements; otherwise there would not be the problems to support the
other debian kernels (like hurd and bsd).

Note, I am not suggesting that this is a fault of systemd. Only systemd
has a different target than debian.

BR
Goffredo


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: systemd set kernel.sysrq=16

2013-11-27 Thread Goffredo Baroncelli

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 that if an user install systemd, he got some
 sysctl values changed.
 Can you send a patch to upstream which will make systemd use a different
 way of achieving that default? If you’ll get it accepted, I’ll gladly
 cherry-pick it and include it in the next Debian upload.
 
 Otherwise, I don’t feel comfortable modifying the upstream software
 package for such a minor detail.

Thanks for your reply and for your time.
However I cannot agree with your conclusion: having some setting changed
only because I installed an unrelated package it seems me a bad
behaviour and definitely not a minor detail. So please don't close
this bug.

I agree with you, that it is a problem of systemd and of its tendency to
force its standard everywhere. But it is its right to do so [1]. What
I am expected by debian package is to filter these issues.

I will highlight this also to upstream. But it would help me if you
don't close this bug.

BR
G.Baroncelli

[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 to the package functionality.

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: systemd set kernel.sysrq=16

2013-10-06 Thread Goffredo Baroncelli

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 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 /usr/lib/sysctl.d/50-default.conf. In 
 this file there is the following entry:

# System Request functionality of the kernel (SYNC)
kernel.sysrq = 16

 which changes the allowable sysrq key. This entry is present also in the
 upstream package.

 Suggested solution:
 Comment the entry kernel.sysrq = 16 in the file 
 /usr/lib/sysctl.d/50-default.conf.
 
 You failed to justify why kernel.sysrq = 16 is a bad default.
 Can you elaborate?

I didn't argue about the default value for kernel.sysrq. I am arguing
that it is not the job of systemd to change/force a value of kernel.sysrq.

Anyway I was not able to find the reason behind this value. May be it is
good for the average user, I don't know. I want to have the ability to
do a Sync, saK, Umount and reBoot when my system crashed.

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
would be sufficient, but it seems not the case

 
 Michael
 
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: systemd set kernel.sysrq=16

2013-10-06 Thread Goffredo Baroncelli

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
 would be sufficient, but it seems not the case

Solved, the configuration file should be processed *before* the default
file.
So I named the file /etc/sysctl.d/01-sysrq.conf.

BR
G.Baroncelli


 

 Michael

 G.Baroncelli
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: systemd set kernel.sysrq=16

2013-10-06 Thread Goffredo Baroncelli

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 that adding a file in /etc/sysctl.d with the MY default
 would be sufficient, but it seems not the case
 
 Solved, the configuration file should be processed *before* the default
 file.
 So I named the file /etc/sysctl.d/01-sysrq.conf.

Unfortunately the things are even more complex. Recently systemd changed
behaviour: with the latest version (207) the configuration must be
processed after the systemd default file: so the file will must be named
/etc/sysctl.d/99-sysrq.conf.



 
 BR
 G.Baroncelli
 
 


 Michael

 G.Baroncelli

 
 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725422: systemd set kernel.sysrq=16

2013-10-05 Thread Goffredo Baroncelli

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 /usr/lib/sysctl.d/50-default.conf. In 
this file there is the following entry:

   # System Request functionality of the kernel (SYNC)
   kernel.sysrq = 16

which changes the allowable sysrq key. This entry is present also in the
upstream package.

Suggested solution:
Comment the entry kernel.sysrq = 16 in the file 
/usr/lib/sysctl.d/50-default.conf.

Further information:
This bug is signalled also for suse [1] and mageia [2]. This entry was added
by the following commit [3] in the systemd git repository.

BR
G.Baroncelli kreij...@gmail.com


[1] Bug 820443 - https://bugzilla.novell.com/show_bug.cgi?id=820443
[2] Bug 10473 - https://bugs.mageia.org/show_bug.cgi?id=10473
[3] 0f59fe5171b5564fc6fb58f3281fbc259c45f7d0 - 
http://cgit.freedesktop.org/systemd/systemd/commit/sysctl.d/50-default.conf?id=0f59fe5171b5564fc6fb58f3281fbc259c45f7d0


-- Package-specific info:
--
systemd-delta:
--

0 overridden configuration files found.

--
systemctl dump:
--
[cut .. cut .. cut]
--
Contents of /var/lib/systemd/deb-systemd-helper-enabled:
--
== 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service
 ==

== 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/lm-sensors.service
 ==

== 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/bind9.service
 ==

== 
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/atd.service 
==

== /var/lib/systemd/deb-systemd-helper-enabled/syslog.service ==

== /var/lib/systemd/deb-systemd-helper-enabled/gpsd.socket.dsh-also ==
/etc/systemd/system/sockets.target.wants/gpsd.socket

== 
/var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/gpsd.socket ==

== /var/lib/systemd/deb-systemd-helper-enabled/gpsd.service.dsh-also ==
/etc/systemd/system/sockets.target.wants/gpsd.socket

== /var/lib/systemd/deb-systemd-helper-enabled/lm-sensors.service.dsh-also ==
/etc/systemd/system/multi-user.target.wants/lm-sensors.service

== 
/var/lib/systemd/deb-systemd-helper-enabled/bind9-resolvconf.service.dsh-also 
==
/etc/systemd/system/bind9.service.wants/bind9-resolvconf.service

== /var/lib/systemd/deb-systemd-helper-enabled/bind9.service.dsh-also ==
/etc/systemd/system/multi-user.target.wants/bind9.service

== /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also ==
/etc/systemd/system/multi-user.target.wants/rsyslog.service
/etc/systemd/system/syslog.service
/etc/systemd/system/multi-user.target.wants/rsyslog.service
/etc/systemd/system/syslog.service
/etc/systemd/system/multi-user.target.wants/rsyslog.service
/etc/systemd/system/syslog.service

== /var/lib/systemd/deb-systemd-helper-enabled/atd.service.dsh-also ==
/etc/systemd/system/multi-user.target.wants/atd.service

== 
/var/lib/systemd/deb-systemd-helper-enabled/accounts-daemon.service.dsh-also ==
/etc/systemd/system/graphical.target.wants/accounts-daemon.service

== 
/var/lib/systemd/deb-systemd-helper-enabled/graphical.target.wants/accounts-daemon.service
 ==

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11.3 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  initscripts  2.88dsf-43
ii  libacl1  2.2.52-1
ii  libaudit11:2.3.2-2
ii  libc62.17-93
ii  libcap2  1:2.22-1.2
ii  libcryptsetup4   2:1.6.1-1
ii  libdbus-1-3  1.6.14-1
ii  libgcrypt11  1.5.3-2
ii  libkmod2 9-3
ii  liblzma5 5.1.1alpha+20120614-2
ii  libpam0g 1.1.3-9
ii  libselinux1  2.1.13-3
ii  libsystemd-daemon0   204-5
ii  libsystemd-journal0  204-5
ii  libsystemd-login0204-5
ii  libudev1 204-5
ii  libwrap0 7.6.q-24
ii  udev 204-5
ii  util-linux   2.20.1-5.5

Versions of packages systemd recommends:
ii  libpam-systemd  204-5

Versions of packages systemd suggests:
ii  systemd-ui  2-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#981176: Rename the doas package as opendoas package

Bug#953537: Info received (xfsdump fails to install in /usr merged system.)

Bug#953537: xfsdump fails to install in /usr merged system.

Bug#882261: Acknowledgement (rsyslog: imjournal doesn't work)

Bug#882261: rsyslog: imjournal doesn't work

Bug#817929: Bug in glibc

Bug#817929: mosh fails to connect, giving a UDP error

Bug#817929: Minimal test case

Bug#817929: mosh and libutempter

Bug#817929: libutempter related problem ?

Bug#817929: mosh fails to connect, giving a UDP error

Bug#737305: libvte9: please include scroll_region_updates.patch from vte3 package

Bug#798083: systemd: Systemd assumes that ESP is mounted in /boot

Bug#778253: libarchive13: archive_read_disk_entry_from_file() and archive_write_disk_set_acls() don't preserv ACL.

Bug#778253: Library version

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

Bug#772744: btrfs-tools: btrfs dev scan called multiple times from udev rules

Bug#772752: btrfs-tools: [Wishlist item] Replace btrfs device scan in initramfs with a udev rule and udevadm trigger -s block

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: Bug#725422: systemd set kernel.sysrq=16

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: Bug#725422: systemd set kernel.sysrq=16

Bug#725422: [Pkg-systemd-maintainers] Bug#725422: systemd set kernel.sysrq=16

Bug#725422: systemd set kernel.sysrq=16

Bug#725422: systemd set kernel.sysrq=16

Bug#725422: systemd set kernel.sysrq=16

Bug#725422: systemd set kernel.sysrq=16

30 matches

Site Navigation

Mail list logo

Footer information