Bug#1072831: getting memory info fails when running under lxc
On Mon 24 Jun 2024, Craig Small wrote: > On Sun, 9 Jun 2024 at 01:03, Paul Slootman wrote: > > I am running a number of virtual systems under lxc via libvirt. > > This means these systems share the host kernel (not like qemu where a > > whole virtual machine is emulated). > Hi Paul, > I did the following (as root) > > lxc-create --name debtest2 --template download -- --dist debian > --release bookworm --arch amd64 > sudo lxc-start --name debtest2 > lxc-attach --name debtest2 I'm running the lxc containers under control of libvirt, I suspect the difference is how libvirt implements the container vs. plain lxc. With libvirt the controlling process is /usr/lib/libvirt/libvirt_lxc , with lxc I see /usr/bin/lxc-start . Regards, Paul
Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]
On Tue 11 Jun 2024, Norbert Schulz wrote: > > If I run rsync without 'z' option the error is: > > [receiver] exceeded --max-alloc=1073741824 setting (file=fileio.c, line=260) > rsync error: error allocating core memory buffers (code 22) at util2.c(80) > [receiver=3.2.7] > rsync: [generator] write error: Broken pipe (32) > rsync: connection unexpectedly closed (18054825 bytes received so far) > [generator] Hmm, you could be running into a memory constraint, are you transferring a very large number of files? If so, is it possible to split the transfer up into smaller parts? Thanks, Paul
Bug#1072990: rsync error: error in rsync protocol data stream (code 12) at token.c(481) [sender=3.2.7]
On Tue 11 Jun 2024, Norbert Schulz wrote: > deflate on token returned 0 (6320 bytes left) [...] > The rsync command is: > rsync -avz --numeric-ids -e ssh --delete --delete-excluded \ Could you try without the 'z' option? There were issues with compression sometimes causing errors. It's also possible that the compression is actually slowing the transfer, if the network is fast enough. Note that '-e ssh' is redundant, that has been default for a long time now. Thanks, Paul
Bug#1072831: getting memory info fails when running under lxc
On Tue 11 Jun 2024, Paul Slootman wrote:
> This works for me. Patch attached.
I see I missed the case lseek() fails with another errno.
Updated patch attached.
Paul
--- library/meminfo.c.orig 2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c 2024-06-11 13:11:12.878627527 +0200
@@ -646,12 +646,20 @@
// clear out the soon to be 'current' values
memset(&info->hist.new, 0, sizeof(struct meminfo_data));
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+}
+else {
+ if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+ if (ESPIPE == errno) {
+ close(info->meminfo_fd);
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+ }
+ else
+ return 1;
+}
for (;;) {
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
Bug#1072831: getting memory info fails when running under lxc
tags 1072831 patch
thanks
On Tue 11 Jun 2024, Craig Small wrote:
> Could you check to see if in the container that lxcfs has overwritten
> the /proc/meminfo file? They sometimes do this for /proc/uptime. They
> might have messed one of the lines up and choked procps; I'm thinking
> like a tab/space at the end of the line or something that looks right
> to a human but not a computer.
The /proc/meminfo in the lxc container is basically the same as that of
the host, except the total memory reflects the limit imposed on the
container. So
-MemTotal:7914164 kB$
+MemTotal:2097152 kB$
and the Slab / SReclaimable / SUnreclaim lines show 0 kB.
> I think we'll need to either run a strace on free or a debugger to see
> where exactly the issue is.
I've been doing this.
Apparently the /proc/meminfo inside the lxc container is not seekable,
errno is ESPIPE.
The code does some seeks to reset to the beginning in preparation for
rereading the file.
I've changed the code to not do an lseek() just after opening the file
(as we should be at the start of the file then anyway), and if the file
is already open, try lseek() and if that returns errno == ESPIPE, then
close and reopen the file.
This works for me. Patch attached.
I don't know whether configure needs to test for existence of ESPIPE;
I do believe it's POSIX.
Paul
--- library/meminfo.c.orig 2023-07-11 11:09:18.436786212 +0200
+++ library/meminfo.c 2024-06-11 10:41:41.643438234 +0200
@@ -646,12 +646,18 @@
// clear out the soon to be 'current' values
memset(&info->hist.new, 0, sizeof(struct meminfo_data));
-if (-1 == info->meminfo_fd
-&& (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY
-return 1;
-
-if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
-return 1;
+if (-1 == info->meminfo_fd) {
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+}
+else {
+ if (lseek(info->meminfo_fd, 0L, SEEK_SET) == -1)
+ if (ESPIPE == errno) {
+ close(info->meminfo_fd);
+ if (-1 == (info->meminfo_fd = open(MEMINFO_FILE, O_RDONLY)))
+ return 1;
+ }
+}
for (;;) {
if ((size = read(info->meminfo_fd, buf, sizeof(buf)-1)) < 0) {
Bug#1072831: getting memory info fails when running under lxc
Package: procps Version: 2:4.0.2-3 Severity: normal I am running a number of virtual systems under lxc via libvirt. This means these systems share the host kernel (not like qemu where a whole virtual machine is emulated). I upgraded one to bookworm today, and when running 'ps faxu' or 'free' I get an error: Unable to create meminfo structure I downgraded procps to 2:3.3.17-5 (including libprocps8 2:3.3.17-5) and then it worked again. Working 'free' output: # free totalusedfree shared buff/cache available Mem: 2097152 64600 19323529028 100200 1932352 Swap: 10338296 795392 9542904 Not working 'free' output: # free free: Unable to create meminfo structure Contents of /proc/meminfo : MemTotal:2097152 kB MemFree: 1930792 kB MemAvailable:1930792 kB Buffers: 0 kB Cached: 100672 kB SwapCached:60812 kB Active: 119140 kB Inactive: 38800 kB Active(anon): 64480 kB Inactive(anon): 84 kB Active(file): 54660 kB Inactive(file):38716 kB Unevictable: 660 kB Mlocked: 43200 kB SwapTotal: 10338296 kB SwapFree:9542904 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 344 kB Writeback: 0 kB AnonPages: 3726656 kB Mapped: 455856 kB Shmem: 9028 kB KReclaimable: 142356 kB Slab: 0 kB SReclaimable: 0 kB SUnreclaim:0 kB KernelStack:8576 kB PageTables:19560 kB SecPageTables:48 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:14295376 kB Committed_AS:7452164 kB VmallocTotal: 34359738367 kB VmallocUsed: 42352 kB VmallocChunk: 0 kB Percpu: 3216 kB HardwareCorrupted: 0 kB AnonHugePages: 3117056 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 179704 kB DirectMap2M: 6940672 kB DirectMap1G: 3145728 kB I'm willing to help debug on my system if needed. Thanks, Paul -- System Information: Debian Release: 12.5 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages procps depends on: ii init-system-helpers 1.65.2 ii libc62.36-9+deb12u4 ii libncursesw6 6.4-4 ii libproc2-0 2:4.0.2-3 ii libtinfo66.4-4 Versions of packages procps recommends: ii psmisc 23.6-1 procps suggests no packages. -- no debconf information
Bug#1036630: procps: unowned /usr/bin/ps on filesystem after upgrade to bookworm
On Tue, 23 May 2023 09:06:31 -0500 C Seys wrote: > After upgrading to bookworm there is an unowned /usr/bin/ps on the filesystem: > > # dpkg -S /usr/bin/ps > dpkg-query: no path found matching pattern /usr/bin/ps > > There is also /bin/ps owned by procps: > > # dpkg -S /bin/ps > procps: /bin/ps I suspect that /bin is now a symlink to /usr/bin . So the /usr/bin/ps you see was installed as /bin/ps Regards, Paul
Bug#1057892: "rsync -a" doesn't set the modification date
On Sun 10 Dec 2023, Harald Dunkel wrote: > Package: rsync > Version: 3.2.7-1 > > If I use > > rsync -SHa datafile usbdisk/ > > to archive a file on exfat (with destdir mounted as > > /dev/sdd2 /usbdisk exfat > rw,nosuid,nodev,noexec,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro > 0 0 > > ), then the mtime is not preserved, if the group ID of datafile is 100. > Error message is something like > > rsync: [receiver] chgrp "/usbdisk/datafile" failed: Operation not > permitted (1) > > If I change the group ID of the source datafile to 1000, the the mtime is set > correctly in the destination directory. > > This is unexpected. Setting UID and GID should be orthogonal to setting the > mtime. When an error occurs when processing a file, the file is not processed further to prevent an escalation of errors. I recommend using --chown 1000:1000 after the -a in this case to prevent this error. I would also strongly recommend removing -SH as I believe exfat does not support sparse files nor hard links. Regards, Paul
Bug#1057376: symbols marked as hidden causes FTBFS in pixmap
Source: libxpm Version: 1:3.5.17-1 Severity: important Tags: patch commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm hides a number of symbols. However a couple of these symbols are used in pixmap, causing a FTBFS on pixmap. These symbols are xpmReadRgbNames and xpmGetRgbName, xpmFreeRgbNames is related. I have confirmed that applying this patch lets pixmap compile successfully. Thanks, Paul -- System Information: Debian Release: 12.2 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled --- src/XpmI.h.orig 2023-11-23 14:44:47.292681988 +0100 +++ src/XpmI.h 2023-12-04 09:45:48.899058512 +0100 @@ -261,10 +261,10 @@ /* RGB utility */ -HFUNC(xpmReadRgbNames, int, (const char *rgb_fname, xpmRgbName *rgbn)); -HFUNC(xpmGetRgbName, char *, (xpmRgbName *rgbn, int rgbn_max, +FUNC(xpmReadRgbNames, int, (const char *rgb_fname, xpmRgbName *rgbn)); +FUNC(xpmGetRgbName, char *, (xpmRgbName *rgbn, int rgbn_max, int red, int green, int blue)); -HFUNC(xpmFreeRgbNames, void, (xpmRgbName *rgbn, int rgbn_max)); +FUNC(xpmFreeRgbNames, void, (xpmRgbName *rgbn, int rgbn_max)); #ifdef FOR_MSW HFUNC(xpmGetRGBfromName,int, (char *name, int *r, int *g, int *b)); #endif
Bug#1054698: pixmap: FTBFS: ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames'
On Fri 27 Oct 2023, Lucas Nussbaum wrote: > Source: pixmap > Version: 2.6.6-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231027 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > /usr/bin/ld: Pixmap.o: in function `Initialize': > > ././Pixmap.c:1145:(.text+0xe631): undefined reference to `xpmReadRgbNames' > > collect2: error: ld returned 1 exit status I've traced this to commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm: Explicitly mark non-static symbols as export or hidden Hides private API from external linkage Signed-off-by: Alan Coopersmith That commit marks those functions as hidden for some reason. I'm contacting the libxpm maintainers. Paul
Bug#1051341: exiftool manpage not complete
Package: libimage-exiftool-perl Version: 12.65+dfsg-1 Severity: wishlist I had an image where I knew the GPS coordinates where it was taken, but I did not have a GPX log. Surely it should be possible to tag a single image with a given coordinate? Reading the manpage it looked like I would have to fake a GPX log... A bit of googling led me to https://exiftool.org/forum/index.php?topic=9415.msg48698#msg48698 wher it was shown that you can do: exiftool testcoord.jpg -gpslatitude=40.2509018273 -gpslongitude=75.1326582499 -gpslatituderef=N -gpslongituderef=W i.e. directly enter the coordinates on the command line. This works! However hint at all about this functionality in any documentation. Perhaps this can be added? Even if only as an extra example in the geotagging examples. Thanks, Paul -- System Information: Debian Release: 12.0 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'oldstable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libimage-exiftool-perl depends on: ii perl 5.36.0-7 Versions of packages libimage-exiftool-perl recommends: ii libarchive-zip-perl 1.68-1 pn libcompress-raw-lzma-perl pn libio-compress-brotli-perl ii libunicode-linebreak-perl 0.0.20190101-1+b5 Versions of packages libimage-exiftool-perl suggests: ii libposix-strptime-perl 0.13-2+b1 -- no debconf information
Bug#865979: at: patch for adding -s option to silence standard messages
Hi,
I notice that my patch again did not make it to an official Debian
release :-(
Attached is the patch updated for 3.2.5.
Paul
diff -ru at-3.2.5.orig/at.1.in at-3.2.5/at.1.in
--- at-3.2.5.orig/at.1.in.orig 2022-02-05 11:00:57.0 +0100
+++ at-3.2.5.orig/at.1.in 2023-06-22 16:02:59.448801528 +0200
@@ -10,7 +10,7 @@
.IR file ]
.RB [ \-u
.IR username ]
-.RB [ \-mMlv ]
+.RB [ \-mMlvs ]
.IR timespec " ...\&"
.br
.B at
@@ -21,7 +21,7 @@
.IR file ]
.RB [ \-u
.IR username ]
-.RB [ \-mMkv ]
+.RB [ \-mMkvs ]
.RB [ \-t
.IR time ]
.br
@@ -278,6 +278,9 @@
.P
Times displayed will be in the format "Thu Feb 20 14:50:00 1997".
.TP
+.B \-s
+Be silent; don't output "job xx at xxx" or "warning: commands will be executed
using /bin/sh" messages when jobs are created.
+.TP
.B
\-c
cats the jobs listed on the command line to standard output.
diff -ru at-3.2.5.orig/at.c at-3.2.5/at.c
--- at-3.2.5.orig/at.c.orig 2022-02-05 11:00:57.0 +0100
+++ at-3.2.5.orig/at.c 2023-06-22 16:05:26.998399592 +0200
@@ -122,6 +122,7 @@
"TERM", "DISPLAY", "_", "SHELLOPTS", "BASH_VERSINFO", "EUID", "GROUPS",
"PPID", "UID"
};
static int send_mail = 0;
+static int silent = 0;
/* External variables */
@@ -543,10 +544,12 @@
close(fd2);
/* This line maybe superfluous after commit
11cb731bb560eb7bff4889c5528d5f776606b0d3 */
-runtime = localtime(&runtimer);
+if (!silent) {
+ runtime = localtime(&runtimer);
-strftime(timestr, TIMESIZE, timeformat, runtime);
-fprintf(stderr, "job %ld at %s\n", jobno, timestr);
+ strftime(timestr, TIMESIZE, timeformat, runtime);
+ fprintf(stderr, "job %ld at %s\n", jobno, timestr);
+}
/* Signal atd, if present. Usual precautions taken... */
fd = open(PIDFILE, O_RDONLY);
@@ -834,7 +837,7 @@
char *pgm;
int program = AT; /* our default program */
-char *options = "q:f:Mmu:bvlrdhVct:"; /* default options for at */
+char *options = "q:f:Mmu:bvlrdhVct:s"; /* default options for at */
int disp_version = 0;
time_t timer = 0;
long *joblist = NULL;
@@ -957,6 +960,10 @@
timeformat = optarg;
break;
+ case 's':
+ silent = 1;
+ break;
+
default:
usage();
break;
@@ -1040,7 +1047,9 @@
It also alows a warning diagnostic to be printed. Because of the
possible variance, we always output the diagnostic. */
- fprintf(stderr, "warning: commands will be executed using /bin/sh\n");
+ if (!silent) {
+ fprintf(stderr, "warning: commands will be executed using
/bin/sh\n");
+ }
writefile(timer, queue);
break;
diff -ru at-3.2.5.orig/panic.c at-3.2.5/panic.c
--- at-3.2.5.orig/panic.c.orig 2022-02-05 11:00:57.0 +0100
+++ at-3.2.5.orig/panic.c 2023-06-22 16:06:14.354912480 +0200
@@ -92,8 +92,8 @@
{
/* Print usage and exit.
*/
-fprintf(stderr, "Usage: at [-V] [-q x] [-f file] [-u username] [-mMlbv]
timespec ...\n"
-" at [-V] [-q x] [-f file] [-u username] [-mMlbv] -t time\n"
+fprintf(stderr, "Usage: at [-V] [-q x] [-f file] [-u username] [-mMlbvs]
timespec ...\n"
+" at [-V] [-q x] [-f file] [-u username] [-mMlbvs] -t time\n"
" at -c job ...\n"
" at [-V] -l [-o timeformat] [job ...]\n"
" atq [-V] [-q x] [-o timeformat] [job ...]\n"
Bug#1031766: ValueError: Namespace Handy not available
Package: numberstation
Version: 1.0.1-2
Severity: normal
There is no manpage... also no README.Debian.
Trying to simply start it:
$ numberstation
Traceback (most recent call last):
File "/usr/bin/numberstation", line 21, in
from numberstation import __main__
File "/usr/share/numberstation/numberstation/__main__.py", line 5, in
from numberstation.window import NumberstationWindow
File "/usr/share/numberstation/numberstation/window.py", line 15, in
gi.require_version('Handy', '1')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Handy not available
It's probably missing some dependency?
As I'm not a python person, I have no idea what the problem is.
-- System Information:
Debian Release: 11.6
APT prefers stable
APT policy: (800, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'unstable'), (100, 'bullseye-fasttrack'), (100,
'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-18-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages numberstation depends on:
ii python3 3.9.2-3
ii python3-gi 3.38.0-2
ii python3-keyring 22.0.1-1
ii python3-pyotp2.3.0-1
numberstation recommends no packages.
numberstation suggests no packages.
-- no debconf information
Bug#1025698: fails to add windows boot loader entry to menu
On Sat 24 Dec 2022, Bernhard Übelacker wrote: > is this issue what the NEWS [1] file notifies about, > to check the need of GRUB_DISABLE_OS_PROBER? > [1] https://sources.debian.org/src/grub2/2.06-7/debian/NEWS/ Thanks, somehow I skipped that. I do want to note that having a double negative in a config is not a nice thing to have: "Disable this? no". Easier to read: "Enable this? yes" "Don't you want this beer?" -- most people will say yes if they *do* want the beer. "Don't you want OS Prober?" "no"...?! Anyway, probably too late now to do anything about this. You can close this bug. Paul
Bug#898157: (no subject)
I can also confirm this; from a "systemctl stop nrpe-ng.service": Dec 18 15:25:40 web2023 systemd[1]: Stopping The next generation Nagios Remote Plugin Executor... Dec 18 15:25:40 web2023 nrpe-ng[754]: received SIGTERM, shutting down... Dec 18 15:25:40 web2023 nrpe-ng[754]: Exception in callback functools.partial( Traceback (most recent call last): File "/usr/lib/python3/dist-packages/tornado/ioloop.py", line 741, in _run_callback ret = callback() File "/usr/lib/python3/dist-packages/tornado/ioloop.py", line 765, in _discard_future_result future.result() File "/usr/lib/python3/dist-packages/tornado/gen.py", line 234, in wrapper yielded = ctx_run(next, result) File "/usr/lib/python3/dist-packages/nrpe_ng/server/server.py", line 182, in sigterm_callback if not io_loop._callbacks and not io_loop._timeouts: AttributeError: 'AsyncIOMainLoop' object has no attribute '_callbacks' Dec 18 15:27:10 web2023 systemd[1]: nrpe-ng.service: State 'stop-sigterm' timed out. Killing. Dec 18 15:27:10 web2023 systemd[1]: nrpe-ng.service: Killing process 754 (nrpe-ng) with signal SIGKILL. Dec 18 15:27:10 web2023 systemd[1]: nrpe-ng.service: Main process exited, code=killed, status=9/KILL Dec 18 15:27:10 web2023 systemd[1]: nrpe-ng.service: Failed with result 'timeout'. Dec 18 15:27:10 web2023 systemd[1]: Stopped The next generation Nagios Remote Plugin Executor. These delays shutdowns and reboots a long time unnessarily. Please fix this. Also, when starting: Dec 18 15:30:04 web2023 systemd[1]: nrpe-ng.service: Can't open PID file /run/nagios/nrpe-ng.pid (yet?) after start: Operation not permitted However this is only cosmetic AFAICS. Thanks, Paul
Bug#1025698: fails to add windows boot loader entry to menu
Package: grub-common
Version: 2.06-7
Severity: important
I upgraded from 2.04-20 to 2.06-7, and after rebooting I discovered
that I could no longer boot my Windows partition.
Downgrading back to 2.04-20 solved this, so only the grub packages
are causing this.
The whole os-prober section is omitted with 2.06-7. This is what
should be there (diff between working and new version):
### BEGIN /etc/grub.d/30_os-prober ###
-menuentry 'Windows Boot Manager (on /dev/nvme1n1p1)' --class windows --class
os $menuentry_id_option 'osprober-efi-2EED-6D4A' {
- insmod part_gpt
- insmod fat
- if [ x$feature_platform_search_hint = xy ]; then
- search --no-floppy --fs-uuid --set=root 2EED-6D4A
- else
- search --no-floppy --fs-uuid --set=root 2EED-6D4A
- fi
- chainloader /EFI/Microsoft/Boot/bootmgfw.efi
-}
### END /etc/grub.d/30_os-prober ###
-- Package-specific info:
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod lvm
insmod ext2
set
root='lvmid/15TLTF-7XHe-ZLKZ-a8Yf-8xrV-oBF8-cmvf23/HS3pws-0NtD-ywVq-goN3-c1BO-FEKX-RdWgTL'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/15TLTF-7XHe-ZLKZ-a8Yf-8xrV-oBF8-cmvf23/HS3pws-0NtD-ywVq-goN3-c1BO-FEKX-RdWgTL'
f81be6e1-8504-475e-b601-150b0802376a
else
search --no-floppy --fs-uuid --set=root f81be6e1-8504-475e-b601-150b0802376a
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod lvm
insmod ext2
set
root='lvmid/15TLTF-7XHe-ZLKZ-a8Yf-8xrV-oBF8-cmvf23/HS3pws-0NtD-ywVq-goN3-c1BO-FEKX-RdWgTL'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint='lvmid/15TLTF-7XHe-ZLKZ-a8Yf-8xrV-oBF8-cmvf23/HS3pws-0NtD-ywVq-goN3-c1BO-FEKX-RdWgTL'
f81be6e1-8504-475e-b601-150b0802376a
else
search --no-floppy --fs-uuid --set=root f81be6e1-8504-475e-b601-150b0802376a
fi
insmod png
if background_image /usr/share/desktop-base/homeworld-theme/grub/grub-16x9.png;
then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-f81be6e1-8504-475e-b601-150b0802376a' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root
788bf1fa-64f6-48f8-b272-1cc11b024c06
echo'Loading Linux 5.10.0-16-amd64 ...'
linux /vmlinuz-5.10.0-16-amd64 root=/dev/mapper/lp250-root ro
echo'Loading initial ramdisk ...'
initrd /initrd.img-5.10.0-16-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-f81be6e1-8504-475e-b601-150b0802376a' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-16-amd64' --class debian
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-5.10.0-16-amd64-advanced-f81be6e1-8504-475e-b601-150b0802376a' {
load_video
insmod gzio
if [ x$gru
Bug#1012191: tzdata: /usr/share/zoneinfo/leap-seconds.list will expire on 2022-06-28 in Debian Stable 11.x/Bullseye
severity 1012191 important thanks The time is ticking, and the leap second data is now due to expire in 20 days. There is a 2022a-1 version in testing. Could this be included in bullseye-updates and perhaps buster-updates? I've downloaded it manually and it seems fine in bullseye. Thanks, Paul
Bug#644973: libedit2: Ctrl+W erases entire line
On Mon 30 May 2022, Paul Slootman wrote: > > .editrc is not even looked for according to strace, at least not in > version 3.1-20191231-2+b1 (I'm using it with the mariadb mysql client). I've since discovered that the version in testing: 3.1-20210910-1 does in fact read the editrc file. According to the upstream changelog: 2021-05-22 Jess Thrysoee [...] * src/el.c: editrc not read on systems without issetugid Patch by Trevor Cordes This version installs just fine on stable (Bullseye). Hopes this helps someone with this problem. Paul
Bug#644973: libedit2: Ctrl+W erases entire line
>> Pressing Ctrl+W erases the entire input line. This is really annoying >> when most other programs (that use readline) bind Ctrl+W to erase the >> current word. > >That's fixable. > >Export EDITRC=/path/to/your/.editrc and put this in that editrc: > >bind "^W" ed-delete-prev-word Doesn't work. .editrc is not even looked for according to strace, at least not in version 3.1-20191231-2+b1 (I'm using it with the mariadb mysql client). According to #975911: : Hi, this is also bugging me on Fedora 32. Digging deep into the : library chain and source code, it almost certainly is a libedit issue. : Linux doesn't have issetugid(), and in src/el.c in libedit : (2019-something thru 20210419 versions) it clearly only reads editrc if : issetugid is available. Thanks, Paul
Bug#1007708: how to disable confirm-paste?
I've since come to discover that the problem I was having, was readline's "enable-bracketed-paste" setting. It seems that confirm-paste is not the problem; however that raises the question: how to *enable* it if you want it? Thanks, Paul
Bug#1007708: how to disable confirm-paste?
Package: rxvt-unicode Version: 9.22-11 Severity: wishlist After 25 years of being able to simply paste multiline selections, now I get nagged about there being more than one line. It took a lot of research to find that this is done by the confirm-paste perl script (it's not documented anywhere besides the frankly quite useless manpage (useless as if you can find the manpage you already know about confirm-paste, and it tells nothing really useful)). Please tell me how this can be disabled? It's not a conffile so removing it will only help until the next update. Note that I'm using fvwm (also for about 25 years :-) in case it matters. Thanks, Paul -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages rxvt-unicode depends on: ii base-passwd 3.5.51 ii libc6 2.33-5 ii libfontconfig12.13.1-4.2 ii libgcc-s1 10.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libperl5.32 5.32.1-4+deb11u2 ii libstartup-notification0 0.12-6+b1 ii libx11-6 2:1.7.2-1 ii libxft2 2.3.2-2 ii libxrender1 1:0.9.10-1 ii ncurses-base 6.2+20201114-2 ii ncurses-term 6.2+20201114-2 Versions of packages rxvt-unicode recommends: ii fonts-dejavu2.37-2 ii fonts-vlgothic [fonts-japanese-gothic] 20200720-1 Versions of packages rxvt-unicode suggests: ii sensible-utils 0.0.14 -- no debconf information
Bug#742241: tmpreaper: please make it easy to use tmpreaper without running it from cron to clean /tmp
Sorry for ignoring this for so long... On Fri 21 Mar 2014, Joost van Baal-Ilić wrote: > Package: tmpreaper > Version: 1.6.13+nmu1 > Severity: wishlist > Tags: patch > > Hi, > > I'd like to use tmpreaper to clean other directories then /tmp. Currently, > this would need editing both /etc/cron.daily/tmpreaper and > /etc/tmpreaper.conf. > Applying this patch in the package would mean the user would have to edit only > one file and, furthermore, would point the user to a way not to suffer from > tmpreapers security issues. Surely if you don't want to run tmpreaper from cron, simply delete the cron.daily script? If you don't use the cron.daily script (either by deleting it or by implementing your suggested patch) then /etc/tmpreaper.conf is not used. So if you want to run tmpreaper manually, just go for it, no need to modify /tmp/tmpreaper.conf. Maybe I've misunderstood what you're trying to do? Regards, Paul
Bug#1000648: clevis: unlocking 2nd device doesn't happen
On Fri 26 Nov 2021, Paul Slootman wrote: > > The reason I think is that the second device is not needed to boot the > system. Presumably there is some way that the initrd scripts determine > what devices need to be decrypted; my problem would probably go away if > the second device gets added to that list. I see in /usr/share/initramfs-tools/hooks/cryptroot around line 182 that the needed lines from /etc/crypttab are selected and copied to the initrd image. Ah! I need to add ",initramfs" to the end of the "extra" encrypted device entries in /etc/crypttab (and re-run update-initramfs -u -v). Now it works! Perhaps this info could be added to a README.Debian in the clevis-luks package? I looked for any documentation but unfortunately there isn't any... I'd consider this bug closed if the initramfs option for crypttab was mentioned in a README. Thanks, Paul
Bug#1000648: clevis: unlocking 2nd device doesn't happen
On Fri 26 Nov 2021, Christoph Biedl wrote: > Paul Slootman wrote... > > > I have 2 MD raid devices which are encrypted. > (...) > > I can't find any hints on how to proceed from here, to have the second > > device also automatically unlocked. Do you have any idea? > > I can't be the only person with more than one LUKS-encrypted device. > > Strange - at a first glance it seems this is > > https://github.com/latchset/clevis/commit/v16-2-g0abdfbc > > That change however was included in 16-2, the version you're using. > Actually, that change was the reason for 16-2. That would trigger if at that moment both devices are decrypted at the same stage. Before I installed clevis, I would first get the passphrase prompt for the first device during the initrd step, and then after the root filesystem is decrypted and mounted, only _then_ did I get asked for the passphrase for the second device. That happens via the /etc/init.d/cryptdisks-early script which is linked to /etc/rcS.d/S08cryptdisks-early . The reason I think is that the second device is not needed to boot the system. Presumably there is some way that the initrd scripts determine what devices need to be decrypted; my problem would probably go away if the second device gets added to that list. Note that I'm one of those old beardy unix people that don't want to like systemd... I see that there is a clevis-systemd package that perhaps should need a clevis-sysvinit counterpart. If that is indeed the case, then I understand if you'd want to tag this "wontfix". However it would be nice if there was some way to unlock all devices during the initrd step. Thanks, Paul
Bug#1000648: clevis: unlocking 2nd device doesn't happen
Source: clevis Version: 16-2 Severity: normal I have 2 MD raid devices which are encrypted. /dev/md1 is a PV for LVM which contains basically the root filesystem and separate /var and /tmp filesystems. /dev/md2 is also a PV for LVM contains /home and other filesystems. I have bound both to the tpm2 pin. /dev/md1 gets succesfully unlocked by the initd.img scripts, but /dev/md2 is not touched there. After the root has been mounted and the cryptdisks-early script runs, that script sees that /dev/md1 has been unlocked, and then proceeds to ask the passphrase for /dev/md2; clevis seems to do nothing for that second device, while it's been bound in an identical manner. I can't find any hints on how to proceed from here, to have the second device also automatically unlocked. Do you have any idea? I can't be the only person with more than one LUKS-encrypted device. PS: dpkg -s clevis-luks ... Description: LUKS integration for clevis This package allows binding a LUKS encrytped volume to a clevis "encrytped" is a typo. Thanks, Paul -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages clevis depends on: ii cracklib-runtime2.9.6-3.4 ii curl7.74.0-1.3+b1 ii jose10-3 ii libc6 2.31-13+deb11u2 ii libjansson4 2.13.1-1.1 ii libjose010-3 ii libpwquality-tools 1.4.4-1 ii libssl1.1 1.1.1k-1+deb11u1 ii luksmeta9-3 Versions of packages clevis recommends: ii cryptsetup-bin 2:2.3.5-1 clevis suggests no packages. -- no debconf information
Bug#997627: pixmap: FTBFS: ar: libdeps specified more than once
On Sat 23 Oct 2021, Lucas Nussbaum wrote: > Source: pixmap > Version: 2.6pl4-20 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211023 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > rm -f libXgnu.a > > ar clq libXgnu.a SelFile.o Path.o Dir.o Draw.o > > ar: libdeps specified more than once > > make[2]: *** [Makefile:1062: libXgnu.a] Error 1 This seems related to #981072 binutils: 'ar clq' does not longer work in latest binutils. With binutils 2.35.2 it works. I suspect that this will affect all packages that use Imake, see also #997628 and #994276. Not that much that I can do about it until xutils-dev gets patched. (Besides patching the output of Imake which is just papering over the binutils screwup.) Paul
Bug#969463: Not on all clients
On Sat 26 Jun 2021, martin f krafft wrote: > Just popping in here the fact that I have two Debian unstable clients > backing up to the same BackupPC server (v3), and while one works fine, the > other does exhibit a problem similar to this one. I am unsure about the hang > and 100% CPU use, but my XferLog file is definitely growing indefinitely, > and the backups are taking forever. Thanks for the update. It most probably is dependent on the data, which means it's not surprising that one client works fine while the other doesn't. It also means it's extremely difficult to track down. Paul
Bug#953366: nvidia-kernel-dkms: module not loaded due lockdown
On Tue 14 Apr 2020, ma...@april.org wrote: > > My problem is solved. > > It was happening because I did signed nvidia-kernel.ko as explained here in: > https://wiki.debian.org/SecureBoot > > In the details, to automate the process for future nvidia-kernel-dmks > update, I relied on this link: > https://gist.github.com/dop3j0e/2a9e2dddca982c4f679552fc1ebb18df It would be helpful if you could write the specifics of that in this bug report, as that page is no longer available. Regards, Paul
Bug#989204: (no subject)
Package: xfce4-settings Version: 4.12.4-1 Severity: wishlist I have a new laptop with hybrid graphics where external monitors are connected via a thunderbolt 3 dock. I haven't managed to get the external monitors working yet, a Nvidia driver problem I believe. However somehow the system does detect that there are monitors connected, and at regular intervals xfce4-display-settings pops up (uselessly, as only the laptop internal screen can be selected, but that's not xfce4-display-settings' fault). At one time I saw there were 30 xfce4-display-settings processes running! I used killall to get rid of them, but IMHO it's pointless to start a new process if there's another still running. So some sort of lock file would be very useful. Thanks, Paul -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-settings depends on: ii libc62.31-12 ii libcairo21.16.0-4+deb10u1 ii libdbus-1-3 1.12.20-0+deb10u1 ii libdbus-glib-1-2 0.110-4 pn libexo-1-0 ii libfontconfig1 2.13.1-2 ii libgarcon-1-00.6.2-1 ii libgarcon-common 0.6.2-1 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.32-3 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libupower-glib3 0.99.10-1 ii libx11-6 2:1.7.1-1 ii libxcursor1 1:1.1.15-2 ii libxfce4ui-1-0 4.12.1-3 ii libxfce4util74.16.0-1 ii libxfconf-0-24.12.1-1 ii libxi6 2:1.7.9-1 ii libxklavier165.4-4 ii libxrandr2 2:1.5.1-1 ii xfconf 4.12.1-1 Versions of packages xfce4-settings recommends: ii x11-utils 7.7+4 xfce4-settings suggests no packages. -- Configuration Files: /etc/xdg/autostart/xfsettingsd.desktop changed: [Desktop Entry] Version=1.0 Name=Xfce Settings Daemon Name[be]=Дэман налад Xfce Name[be@tarask]=Сэрвіс наладаў Xfce Name[bg]=Демон за настройките на Xfce Name[ca]=Dimoni del gestor d'ajusts de Xfce Name[cs]=Démon nastavení prostředí Xfce Name[da]=Xfce-indstillingsdæmon Name[de]=Xfce-Einstellungsdienst Name[en_CA]=Xfce Settings Daemon Name[es]=Servicio de configuración de Xfce Name[et]=Xfce seadete taustaprotsess Name[eu]=Xfce ezarpen deabrua Name[fi]=Xfce:n asetustaustaprosessi Name[fr]=Service des paramètres Xfce Name[gl]=Servizo de configuración do Xfce Name[he]=שדון ההגדרות של Xfce Name[hr]=Xfce nadglednik postavki Name[hu]=Xfce beállításkezelő démon Name[id]=Jurik Pengaturan Xfce Name[ie]=Daemon de parametres de Xfce Name[it]=Demone delle impostazioni di Xfce Name[ja]=Xfce 設定デーモン Name[kk]=Xfce баптаулар қызметі Name[ko]=Xfce 설정 데몬 Name[lt]=Xfce nustatymų tarnyba Name[ms]=Daemon Tetapan Xfce Name[nb]=Bakgrunnsprosess for Xfce-innstillinger Name[nl]=Achtergronddienst voor Xfce-instellingen Name[pl]=Demon ustawień Xfce Name[pt]=Serviço de definições do Xfce Name[pt_BR]=Daemon de configurações do Xfce Name[ru]=Служба диспетчера настроек Xfce Name[sl]=Pritajene Xfce nastavitve Name[sq]=Demoni Xfce i Rregullimeve Name[sr]=Домар поставки ИксФЦЕ-а Name[sv]=Konfigurationsdemon för Xfce Name[tr]=Xfce Ayarlar Süreci Name[zh_CN]=Xfce 设置守护进程 Name[zh_TW]=Xfce 設定幕後程式 Comment=The Xfce Settings Daemon Comment[am]=የ Xfce ማሰናጃ እረዳት Comment[ar]=بريمج إعدادات إكسفس Comment[ast]=El degorriu d'axustes Xfce Comment[be]=Дэман налад Xfce Comment[be@tarask]=Сэрвіс наладаў Xfce Comment[bg]=Управлението на настройките на Xfce Comment[ca]=El dimoni del gestor d'ajusts de Xfce Comment[cs]=Démon nastavení prostředí Xfce Comment[da]=Xfce-indstillingsdæmonen Comment[de]=Der Xfce-Einstellungsdienst Comment[el]=Διαχειριστής Ρυθμίσεων Xfce Comment[en_AU]=The Xfce Settings Daemon Comment[en_CA]=The Xfce Settings Daemon Comment[en_GB]=The Xfce Settings Daemon Comment[es]=El servicio de configuración de Xfce Comment[et]=Xfce seadete taustaprotsess Comment[eu]=Xfce ezarpen deabrua Comment[fi]=Xfce:n asetustaustaprosessi Comment[fr]=Le démon des paramètres Xfce Comment[gl]=O daemon de configuración de Xfce Comment[he]=תהליך רקע הגדרות של Xfce Comment[hr]=Xfce nadglednik postavki Comment[hu]=Az Xfce beállításkezelő démon Comment[hy_AM]=Xfce֊ի կարգաւորումների աւժանդակ ծրագիր Comment[hye]=Xfce֊ի կարգաւորումների աւժանդակ ծրագիր Comment[id]=Jurik Pengaturan Xfce Comment[ie]=Dæmon de parametres de Xfce Comment[is]=XFCE Stillingamiðlarinn Comment[it]=Demone delle impostazioni di Xfce Comment[ja]=Xfce 設定デーモン Comment[kk]=Xfce баптаулар қызметі Comment[ko]=Xfce 설정 데몬 Comment[lt]=Xfce nustatymų tarnyba Comment[lv]=Xfce iestatījumu dēmons Comment[ms]=D
Bug#969463: Stops on big files
On Mon 19 Apr 2021, Philipp Marek wrote: > > /usr/bin/time rsync -va --inplace --no-whole-file --block-size=65536 > --progress --stats \ > /var/lib/libvirt/images/vm.qcow2 /mnt/tmp3/vm.qcow2 Hi, Could you also try it without the --block-size=65536 option? Paul
Bug#986731: wireshark: packet bytes frame doesn't show all ASCII bytes
Package: wireshark Version: 3.4.4-1 Severity: normal When viewing packets from a capture file, I found that the ASCII decoding of the bytes doesn't show most of the last 8 bytes on each row of 16. This is an example of what is shown: 00 e0 4c dc 45 db 00 f7 01 fc c5 31 08 00 45 00 ..L.E... 0010 00 40 a7 86 40 00 40 11 39 36 ac 12 01 ca ac 12 .@..@.@. 0020 00 02 4b e4 00 35 00 2c c5 f9 30 50 01 00 00 01 ..K..5., 0030 00 00 00 00 00 00 05 67 72 61 70 68 08 66 61 63 ...g 0040 65 62 6f 6f 6b 03 63 6f 6d 00 00 01 00 01 ebook.co m. Curiously, right click and "Copy Bytes as Hex + ASCII Dump" does result in the following being copied: 00 e0 4c dc 45 db 00 f7 01 fc c5 31 08 00 45 00 ..L.E..1..E. 0010 00 40 a7 86 40 00 40 11 39 36 ac 12 01 ca ac 12 .@..@.@.96.. 0020 00 02 4b e4 00 35 00 2c c5 f9 30 50 01 00 00 01 ..K..5.,..0P 0030 00 00 00 00 00 00 05 67 72 61 70 68 08 66 61 63 ...graph.fac 0040 65 62 6f 6f 6b 03 63 6f 6d 00 00 01 00 01 ebook.com. In the example above all but the last line had the problem, however on some data a couple of ASCII characters are shown on the right part, but still not all. I have not been able to find a pattern when a byte is shown or not. I noticed this on 3.4.2-1, tried updating to 3.4.4-1 but that didn't make any difference. Thanks, Paul -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FORCED_RMMOD, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages wireshark depends on: ii wireshark-qt 3.4.4-1 wireshark recommends no packages. wireshark suggests no packages. -- no debconf information
Bug#983568: gimp: dependency on libbabl needs tightening
Package: gimp Version: 2.10.22-2 Severity: normal The dependency is now: libbabl-0.1-0 (>= 0.1.10) However, start this version of gimp presents a popup stating: BABL version too old! GIMP requires BABL version 0.1.78 or later. Installed BABL version is 0.1.74. Somehow you or your software packager managed to install GIMP with an older BABL version. Please upgrade to BABL version 0.1.78 or later. Yes, I did not upgrade everything at once. However if the package does have such an explicit dependency, that should be reflected in the packaging. Thanks, Paul -- System Information: Debian Release: bullseye/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FORCED_RMMOD, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages gimp depends on: ii gimp-data2.10.22-2 ii libaa1 1.4p5-46+b1 ii libbabl-0.1-01:0.1.74-dmo1 ii libbz2-1.0 1.0.8-2 ii libc62.30-4 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.1-2 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libgegl-0.4-01:0.4.26-2 ii libgexiv2-2 0.12.0-2 ii libgimp2.0 2.10.22-2 ii libglib2.0-0 2.64.2-1 ii libgs9 9.53.3~dfsg-6 ii libgtk2.0-0 2.24.32-4 ii libgudev-1.0-0 233-1 ii libharfbuzz0b2.6.4-1 ii libheif1 1.10.0-2 ii libilmbase25 2.5.4-1 ii libjpeg62-turbo 1:2.0.5-1.1 ii libjson-glib-1.0-0 1.6.0-2 ii liblcms2-2 2.9-4+b1 ii liblzma5 5.2.4-1+b1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.5-1 1:1.5.1-dmo2 ii libopenexr25 2.5.4-1 ii libopenjp2-7 2.3.1-1 ii libpango-1.0-0 1.46.2-1 ii libpangocairo-1.0-0 1.46.2-1 ii libpangoft2-1.0-01.46.2-1 ii libpng16-16 1.6.37-3 ii libpoppler-glib8 20.09.0-3.1 ii librsvg2-2 2.48.3-1 ii libstdc++6 10.2.1-6 ii libtiff5 4.1.0+git191117-2 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-17 ii libx11-6 2:1.7.0-2 ii libxcursor1 1:1.2.0-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-2 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gimp recommends: ii ghostscript 9.53.3~dfsg-6 Versions of packages gimp suggests: ii gimp-data-extras 1:2.0.2-1.1 pn gimp-help-en | gimp-help pn gvfs-backends ii libasound21.2.2-2.1 -- no debconf information
Bug#981184: firefox-esr: doesn't load pages over internet
On Fri, 29 Jan 2021 17:14:50 +0900 Mike Hommey wrote: > On Thu, Jan 28, 2021 at 07:31:32PM +0900, Mike Hommey wrote: > > On Thu, Jan 28, 2021 at 11:04:23AM +0100, Emilian Nowak wrote: > > > On 2021-01-28, at 06:17:07 Mike Hommey wrote: > > > > > > > Can you try upgrading libnss3? > > > > > > After upgrading from > > > > > > libnss3: 2:3.56-1 > > > to 2:3.60-1 firefox works normally. > > > > > > Thanks for tip. > > > > > > Shouldn't this firefox version depend on this version of libnss3 ? > > > > firefox does the right thing, but the patch is not applied to > > firefox-esr yet. > > Actually, they both have what I was thinking about. This is another > issue :( > > Mike > >
Bug#976190: systemd: LXC memory limits messed up after some time
Hi, On Tue 01 Dec 2020, Michael Biebl wrote: > > > > root@dns:~# free > >totalusedfree shared buff/cache > > available > > Mem:1048576 41660 1006784 48124 132 > > 1006784 > > Swap: 0 0 0 > > > > > > After some time, I have noticed that they are no longer correct; in fact > > they are wildly wrong: > > > > root@dns:~# free > >totalusedfree shared buff/cache > > available > > Mem:9007199254740991 598372 9007199254108535 85652 > > 34084 9007199254108535 > > Swap: 01692 -1692 > > > > I suppose, this is from within the container? Yes, correct > How do you apply/setup the limits? This is in the libvirt container definition: dns 32bd6117-0082-49eb-b622-87e1de716c88 1048576 1048576 1048576 1048576 1048576 1 Paul
Bug#971837: libvirt-daemon: apparmor error when creating VM
I've since found that the problem is in fact the location of the ISO file. When I moved it from /usr/local/lib/ to /var/lib/libvirt/images/ the creation of the VM succeeded. In short the error message given bij libvirt is VERY misleading! That is probably the real bug. I would appreciate a hint how to add /usr/local/lib/ as a location for ISO files. Adding these lines to /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper didn't help: /usr/local/lib/ r, /usr/local/lib/*.[Ii][Ss][Oo] r, Thanks, Paul
Bug#971837: libvirt-daemon: apparmor error when creating VM
Package: libvirt-daemon
Version: 5.0.0-4+deb10u1
Severity: normal
I tried creating a VM as follows:
-
# virt-install --accelerate --hvm --connect qemu:///system \
--cdrom /usr/local/lib/faime-.iso --os-variant debian10 \
--name vm008-0 \
--disk path=/var/lib/libvirt/images/vm008-0,size=6 \
--graphics=vnc,listen=0.0.0.0,port=5900 \
--ram 2048 \
--network bridge=br0,model=virtio \
--network bridge=brnfs,model=virtio \
--noreboot
WARNING Unable to connect to graphical console: virt-viewer not installed.
Please install the 'virt-viewer' package.
WARNING No console to launch for the guest, defaulting to --wait -1
Starting install...
Allocating 'vm008-0'| 6.0 GB 00:00
ERRORinternal error: cannot load AppArmor profile
'libvirt-cf414ff7-d783-449b-a0c8-6169ec41dfca'
Removing disk 'vm008-0' |0 B 00:00
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start vm008-0
otherwise, please restart your installation.
-
Note the "cannot load AppArmor profile".
I have verified that editing /etc/libvirt/qemu.conf and adding
security_driver="none'
removes this error, however I would prefer having apparmor active.
There is a line in /etc/apparmor.d/usr.sbin.libvirtd :
change_profile -> @{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
which should match the profile filename given in the error message.
The system is up to date with buster as of today.
Please help fixing this problem.
Thanks,
Paul
-- System Information:
Debian Release: 10.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-11-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libvirt-daemon depends on:
ii libacl1 2.2.53-4
ii libapparmor12.13.2-10
ii libaudit1 1:2.8.4-3
ii libavahi-client30.7-4+b1
ii libavahi-common30.7-4+b1
ii libblkid1 2.33.1-0.1
ii libc6 2.28-10
ii libcap-ng0 0.7.9-2
ii libcurl3-gnutls 7.64.0-4+deb10u1
ii libdbus-1-3 1.12.20-0+deb10u1
ii libdevmapper1.02.1 2:1.02.155-3
ii libfuse22.9.9-1+deb10u1
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.7-4+deb10u5
ii libnetcf1 1:0.2.8-1+b2
ii libnl-3-200 3.4.0-1
ii libnl-route-3-200 3.4.0-1
ii libnuma12.0.12-1
ii libparted2 3.2-25
ii libpcap0.8 1.8.1-6
ii libpciaccess0 0.14-1
ii libsasl2-2 2.1.27+dfsg-1+deb10u1
ii libselinux1 2.8-1+b1
ii libssh2-1 1.8.0-2.1
ii libudev1241-7~deb10u4
ii libvirt05.0.0-4+deb10u1
ii libxenmisc4.11 4.11.4+37-g3263f257ca-1
ii libxenstore3.0 4.11.4+37-g3263f257ca-1
ii libxenstore3.0 4.11.4+37-g3263f257ca-1
ii libxentoollog1 4.11.4+37-g3263f257ca-1
ii libxml2 2.9.4+dfsg1-7+b3
ii libyajl22.1.0-3
Versions of packages libvirt-daemon recommends:
pn libxml2-utils
ii netcat-openbsd 1.195-2
ii qemu-kvm1:3.1+dfsg-8+deb10u8
Versions of packages libvirt-daemon suggests:
pn libvirt-daemon-driver-storage-gluster
pn libvirt-daemon-driver-storage-rbd
pn libvirt-daemon-driver-storage-zfs
ii libvirt-daemon-system 5.0.0-4+deb10u1
pn numad
Bug#971627: 100% cpu on resume of transfer
On Sat 03 Oct 2020, Kurt Roeckx wrote: > On Sat, Oct 03, 2020 at 02:08:54PM +0200, Paul Slootman wrote: > > On Sat 03 Oct 2020, Kurt Roeckx wrote: > > > > > > I was transfering a large file using rsync (3 TB). The connection > > > broke after about 1 TB. I was using the -P option. So I restarted > > > the transfer. But that transfer resulted in 100% CPU usage on the > > > sender side, and limiting the transfer to about 1.5 MB/s. > > > > > > It also seems that when I restart the transfer, it first reads the > > > 1 TB on the client side, and then reads the 1 TB on the sender > > > side, causing a large delay before restarting the transfer. > > > > This is normal, as rsync first has to verify that the 1TB on the > > destination is correct and identical to the data on the source. > > > > If you are certain that the part already transmitted to the destination > > is correct, you can use --append to only send the remaining part of the > > file. > > Is the 100% CPU usage also expected? Yes, that's the checksum algorithm running. Paul
Bug#969463: rsync: fails reproducible but unexplained on a specific volume, breaks horribly when started by BackupPC
On Thu 03 Sep 2020, Andreas Feldner wrote: > 2) rsync test run > > -- rsync stdout > opening connection using: ssh -l root localhost rsync --server --sender > -vvvlHogDtprxe.iLsfxCIvu -B2048 --numeric-ids . /var/lib/lxc (12 args) How are you invoking rsync? Please give the exact command line, including what you current working directory is. Are you actually using ssh to connect to localhost and transferring the data over that ssh link? If so, then these lines are very strange in the case (1) text: > Got remote protocol 31 > Negotiated protocol version 28 I would expect an rsync to negotiate the highest protocol version possible, so this looks like it's talking to a newer version than itself. > receiving incremental file list > server_sender starting pid=144226 > [sender] make_file(lxc,*,0) > send_file_list done > [sender] pushing local filters for /var/lib/lxc/ > <> > got file_sum > set modtime, atime of lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to > (1596971541) 2020/08/09 13:12:21, (1599125234) 2020/09/03 11:27:14 > renaming lxc/nextcloud/rootfs/var/backups/.gshadow.bak.vcUsMX to > lxc/nextcloud/rootfs/var/backups/gshadow.bak > recv_files(lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar) > lxc/nextcloud/rootfs/var/backups/nextcloud-dir_20200119.tar > [receiver] _exit_cleanup(code=13, file=log.c, line=245): about to call > exit(13) > [generator] _exit_cleanup(code=13, file=io.c, line=1644): about to call > exit(13) > -- end of stdout > > -- rsync stderr > rsync error: errors with program diagnostics (code 13) at log.c(245) > [receiver=3.2.3] > rsync: [generator] write error: Broken pipe (32) > -- end of stderr Because of the "errors with program diagnostics" I would have expected more messages... It would be most helpful if you could follow the instructions on https://rsync.samba.org/issues.html especially de second half of question 3. Paul
Bug#968196: fping: postinst fails when dpkg-statoverride is already used
Package: fping Version: 4.2-3 Severity: normal Setting up fping (4.2-3) ... Failed to set capabilities on file `/usr/bin/fping' (Operation not supported) The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file WARNING: 'setcap cap_net_raw+ep /usr/bin/fping' failed. /usr/bin/fping is already setuid root. Not trying to fix anything. WARNING: Making /usr/bin/fping setuid instead. Use dpkg-statoverride(1) to change that if you're unhappy with it. dpkg-statoverride: error: an override for '/usr/bin/fping' already exists; aborting dpkg: error processing package fping (--configure): installed fping package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: fping E: Sub-process /usr/bin/dpkg returned an error code (1) The script first says "Not trying to fix anything" and then goes on and tries to fix something. The problem is that there is an "else" missing: --- fping.postinst.orig 2020-08-10 14:41:18.835956683 +0200 +++ fping.postinst 2020-08-10 12:20:13.191669951 +0200 @@ -14,9 +14,10 @@ else echo "A local statoverride for /usr/bin/fping already exists. Not trying to fix anything." 1>&2 fi + else +echo "WARNING: Making /usr/bin/fping setuid instead. Use dpkg-statoverride(1) to change that if you're unhappy with it." 1>&2 +dpkg-statoverride --update --add root root 4755 /usr/bin/fping fi -echo "WARNING: Making /usr/bin/fping setuid instead. Use dpkg-statoverride(1) to change that if you're unhappy with it." 1>&2 -dpkg-statoverride --update --add root root 4755 /usr/bin/fping fi fi ;; -- Package-specific info: -rwxr-xr-x 1 root root 48032 Apr 27 15:37 /usr/bin/fping lrwxrwxrwx 1 root root 5 Apr 27 15:37 /usr/bin/fping6 -> fping -- System Information: Debian Release: bullseye/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages fping depends on: ii libc62.30-4 ii libcap2-bin 1:2.33-1 ii netbase 6.1 fping recommends no packages. fping suggests no packages. -- no debconf information
Bug#865979: at: patch for adding -s option to silence standard messages (updated for 3.1.23)
Hi,
I was wondering why -s didn't work after upgrading to buster, and
remembered that was a patch I had made myself.
Unfortunately it seems not to have been integrated yet. Here is the
patch updated for 3.1.23.
Please add it. Maybe forward upstream?
Paul
diff -ru at-3.1.23.orig/at.1.in at-3.1.23/at.1.in
--- at-3.1.23.orig/at.1.in.orig 2018-07-24 14:41:23.0 +0200
+++ at-3.1.23.orig/at.1.in 2020-07-26 14:08:33.796355635 +0200
@@ -8,7 +8,7 @@
.IR queue ]
.RB [ \-f
.IR file ]
-.RB [ \-mMlv ]
+.RB [ \-mMlvs ]
.IR timespec " ...\&"
.br
.B at
@@ -17,7 +17,7 @@
.IR queue ]
.RB [ \-f
.IR file ]
-.RB [ \-mMkv ]
+.RB [ \-mMkvs ]
.RB [ \-t
.IR time ]
.br
@@ -257,6 +257,9 @@
.P
Times displayed will be in the format "Thu Feb 20 14:50:00 1997".
.TP
++.B \-s
++Be silent; don't output "job xx at xxx" or "warning: commands will be
executed using /bin/sh" messages when jobs are created.
++.TP
.B
\-c
cats the jobs listed on the command line to standard output.
diff -ru at-3.1.23.orig/at.c at-3.1.23/at.c
--- at-3.1.23.orig/at.c 2018-07-24 14:41:23.0 +0200
+++ at-3.1.23/at.c 2020-07-26 14:12:09.951471012 +0200
@@ -116,6 +116,7 @@
"TERM", "DISPLAY", "_", "SHELLOPTS", "BASH_VERSINFO", "EUID", "GROUPS",
"PPID", "UID"
};
static int send_mail = 0;
+static int silent = 0;
/* External variables */
@@ -512,10 +513,12 @@
close(fd2);
-runtime = localtime(&runtimer);
+if (!silent) {
+ runtime = localtime(&runtimer);
-strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
-fprintf(stderr, "job %ld at %s\n", jobno, timestr);
+ strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
+ fprintf(stderr, "job %ld at %s\n", jobno, timestr);
+}
/* Signal atd, if present. Usual precautions taken... */
fd = open(PIDFILE, O_RDONLY);
@@ -749,7 +752,7 @@
char *pgm;
int program = AT; /* our default program */
-char *options = "q:f:MmbvlrdhVct:";/* default options for at */
+char *options = "q:f:MmbvlrdhVct:s"; /* default options for at */
int disp_version = 0;
time_t timer = 0;
struct passwd *pwe;
@@ -864,6 +867,10 @@
timer -= timer % 60;
break;
+ case 's':
+ silent = 1;
+ break;
+
default:
usage();
break;
@@ -946,7 +953,9 @@
It also alows a warning diagnostic to be printed. Because of the
possible variance, we always output the diagnostic. */
- fprintf(stderr, "warning: commands will be executed using /bin/sh\n");
+ if (!silent) {
+ fprintf(stderr, "warning: commands will be executed using
/bin/sh\n");
+ }
writefile(timer, queue);
break;
diff -ru at-3.1.23.orig/panic.c at-3.1.23/panic.c
--- at-3.1.23.orig/panic.c 2018-07-24 14:41:23.0 +0200
+++ at-3.1.23/panic.c 2020-07-26 14:12:56.671279837 +0200
@@ -92,8 +92,8 @@
{
/* Print usage and exit.
*/
-fprintf(stderr, "Usage: at [-V] [-q x] [-f file] [-mMlbv] timespec ...\n"
-" at [-V] [-q x] [-f file] [-mMlbv] -t time\n"
+fprintf(stderr, "Usage: at [-V] [-q x] [-f file] [-mMlbvs] timespec ...\n"
+" at [-V] [-q x] [-f file] [-mMlbvs] -t time\n"
" at -c job ...\n"
" atq [-V] [-q x]\n"
" at [ -rd ] job ...\n"
Bug#961929: rsync: syntax for multiple files from remote host seems not working when files are in different modules
On Sun 31 May 2020, furio wrote: > > using this rsyncd.conf: > > -- > use chroot = yes > [a] > comment = a folder > path = /home/rsync-test/files/a > [b] > comment = b folder > path = /home/rsync-test/files/b > -- > > The command > > rsync 127.0.0.1::b/y ::b/z . > > runs as expected, synchronizing files y and z with no errors. However, a > problem appears when the files are located in different modules: > > rsync 127.0.0.1::b/y ::a/x . > > fails with > > rsync: change_dir "/a" (in b) failed: No such file or directory (2) > rsync error: some files/attrs were not transferred (see previous > errors) (code 23) at main.c(1677) [generator=3.1.3] > > y has been synchronized, but x was not. The situation remains the same when > the host is explicitly added to the second argument. Similarly, adding the > quotes (old style syntax) does not help. > > Possibly I am misunderstanding something; this behaviour baffles me. When using modules, rsync makes a connection to the daemon, and requests connection to that module. That module specifies a path that is the root of the transfer, and may also specify exclusions, user and group IDs, and all sorts of extra settings e.g. lock file, syslog facility, read only, etc. . It is way too complicated to be able to switch modules on the fly during one connection, so the specification only allows one module to be used with an rsync daemon per connection. You can see that it assumes that "::a/x" means the file "a/x" in the module already specified: "b", hence the error "change_dir "/a" (in b) failed:". There is very little chance of your usage being supported anytime, simply due to just about any option being able to be set differently per module. There is also not much advantage in combining usage of more than one module per connection, there is little overhead compared to an ssh connection. Paul
Bug#949573: rsync systemd unit ignore default file
On Wed 22 Jan 2020, Pavel Rau?? wrote: > > The rsync daemon starting via systemd unit including in the package ignore > variables in file /etc/default/rsync. > > > > Could you fix this issue by adding EnvironmentFile into Service part of > systemd unit? > > EnvironmentFile=-/etc/default/rsync Unfortunately it's not that simple, those variables are not directly used by the rsync daemon; they were used in the init.d script to modify how rsync is started. As the default file says: # This file is only used for init.d based systems! # If this system uses systemd, you can specify options etc. for rsync # in daemon mode by copying /lib/systemd/system/rsync.service to # /etc/systemd/system/rsync.service and modifying the copy; add required # options to the ExecStart line. Paul
Bug#881725: NMU for tmpreaper
On Fri 06 Sep 2019, Thijs Kinkhorst wrote: > > As I already mentioned on IRC - we're running into this issue (Apache > stopped running periodically) and since a patch has been available for a > few months I took the liberty to schedule a NMU in DELAYED/5 with this fix. > > Let me know if you object or even if you want me to go ahead without delay. Sure, go ahaed. Thanks, Paul
Bug#931781: rsync: Buster hangs when rsyncing large (400M) files over ssh. Same hardware works OK with Stretch
Seeing the error messages you are getting, it sounds like there is a memory shortage, possibly the vmware ballooning driver is failing to provide sufficient memory in time. It does not look like rsync is to blame for your problems. Paul
Bug#403369: initscripts: boot messages not displayed on serial console with bootlogd enabled
On Tue 14 May 2019, Dmitry Bogatov wrote: > > Seems things changed for 13 years. I just set up virtual machine with > following kernel options: > > console=tty0 console=ttyS0,9600n > > and runit with "kvm -serial file:serial". When it booted content of > /var/log/boot in VM and "serial" on host was same -- both listed events > up to openssh service. > > So, seems I need more information and guidance to debug this issue. You do have bootlogd installed? I would suggest removing the "console=tty0" as this happened on a system with only serial, no display. However, as that system has since been recycled, I can't reproduce it either anymore, so I suggest that the bug may be closed as far as I am concerned. Thanks, Paul
Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1
On Sun 14 Apr 2019, Adam D. Barratt wrote: > > Apologies for having let this slip off the radar a little. NP > I just flagged the current upload to be rejected. Please re-build the > package with "stretch" in the changelog rather than "stretch-security", > and feel free to go ahead with the re-upload once dak confirms that the > reject has been actioned. I've just uploaded it. Thanks, Paul
Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1
On Wed 03 Apr 2019, Adam D. Barratt wrote: > > > > There doesn't appear to be an uploaded version anywhere that I can see. > > This now happened, but > > > Please attach a source debdiff to this report. > > this hasn't. If it had, I'd have asked you to rebuild the package so the > changelog didn't claim it was uploaded to stretch-security (I'm still > debating whether to do so anyway, as it'll be less confusing for users). I'm willing to do whatever you think is best, please feel free to tell me what to do :-) Thanks and sorry for the bother, Paul
Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1
On Sun 31 Mar 2019, Adam D. Barratt wrote: > > Because: > > Mar 15 10:54:14 /rsync_3.1.2-1+deb9u2_amd64.changes has bad PGP/GnuPG > signature! Damn, as this had to be built on a stretch system I had my old key on there :( Re-signed, and re-uploaded. Paul
Bug#924641: unblock: rsync/3.1.3-6
On Fri 15 Mar 2019, Emilio Pozuelo Monfort wrote: > On 15/03/2019 11:35, Paul Slootman wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package rsync > > > > There is a grave bug #924509 reported against rsync, due to some CVEs > > from 2016 on the zlib code that haven't been patched yet. This version > > only adds the patches from those 4 CVEs. > > It also changes the strip invocation on d/rules. Why? Hmm, I'l have to reinvestigate how I make the debdiff, as that didn't show that, which is why I didn't notice this. I had changed that already a month ago, but hadn't needed to upload a new version in the meantime (and forgot about this change in the meantime). The change in strip invocation was to comply with policy 4.3.0: - 10.1 By default all installed binaries should be stripped by calling strip --strip-unneeded --remove-section=.comment --remove-section=.note binaries on the binaries after they have been copied into "debian/tmp" but before the tree is made into a package. - Do you prefer I build a new version with that change reverted? Thanks, Paul
Bug#924641: unblock: rsync/3.1.3-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package rsync
There is a grave bug #924509 reported against rsync, due to some CVEs
from 2016 on the zlib code that haven't been patched yet. This version
only adds the patches from those 4 CVEs.
Thanks!
unblock rsync/3.1.3-5
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.6-wurtel-ws (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
diff -Nru rsync-3.1.3/debian/changelog rsync-3.1.3/debian/changelog
--- rsync-3.1.3/debian/changelog2019-01-26 13:05:25.0 +0100
+++ rsync-3.1.3/debian/changelog2019-03-15 11:25:01.0 +0100
@@ -1,3 +1,10 @@
+rsync (3.1.3-6) unstable; urgency=medium
+
+ * Apply CVEs from 2016 to the zlib code.
+closes:#924509
+
+ -- Paul Slootman Fri, 15 Mar 2019 11:25:01 +0100
+
rsync (3.1.3-5) unstable; urgency=medium
* d/rules: fix sorting for reproducible builds, in the previous release
diff -Nru rsync-3.1.3/debian/patches/CVE-2016-9840.patch
rsync-3.1.3/debian/patches/CVE-2016-9840.patch
--- rsync-3.1.3/debian/patches/CVE-2016-9840.patch 1970-01-01
01:00:00.0 +0100
+++ rsync-3.1.3/debian/patches/CVE-2016-9840.patch 2019-03-15
11:25:01.0 +0100
@@ -0,0 +1,71 @@
+>From 6a043145ca6e9c55184013841a67b2fef87e44c0 Mon Sep 17 00:00:00 2001
+From: Mark Adler
+Date: Wed, 21 Sep 2016 23:35:50 -0700
+Subject: [PATCH] Remove offset pointer optimization in inftrees.c.
+
+inftrees.c was subtracting an offset from a pointer to an array,
+in order to provide a pointer that allowed indexing starting at
+the offset. This is not compliant with the C standard, for which
+the behavior of a pointer decremented before its allocated memory
+is undefined. Per the recommendation of a security audit of the
+zlib code by Trail of Bits and TrustInSoft, in support of the
+Mozilla Foundation, this tiny optimization was removed, in order
+to avoid the possibility of undefined behavior.
+---
+ inftrees.c | 18 --
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+diff --git a/zlib/inftrees.c b/zlib/inftrees.c
+index 22fcd666..0d2670d5 100644
+--- a/zlib/inftrees.c
b/zlib/inftrees.c
+@@ -54,7 +54,7 @@ unsigned short FAR *work;
+ code FAR *next; /* next available space in table */
+ const unsigned short FAR *base; /* base value table to use */
+ const unsigned short FAR *extra;/* extra bits table to use */
+-int end;/* use base and extra for symbol > end */
++unsigned match; /* use base and extra for symbol >= match */
+ unsigned short count[MAXBITS+1];/* number of codes of each length */
+ unsigned short offs[MAXBITS+1]; /* offsets in table for each length */
+ static const unsigned short lbase[31] = { /* Length codes 257..285 base */
+@@ -181,19 +181,17 @@ unsigned short FAR *work;
+ switch (type) {
+ case CODES:
+ base = extra = work;/* dummy value--not used */
+-end = 19;
++match = 20;
+ break;
+ case LENS:
+ base = lbase;
+-base -= 257;
+ extra = lext;
+-extra -= 257;
+-end = 256;
++match = 257;
+ break;
+ default:/* DISTS */
+ base = dbase;
+ extra = dext;
+-end = -1;
++match = 0;
+ }
+
+ /* initialize state for loop */
+@@ -216,13 +214,13 @@ unsigned short FAR *work;
+ for (;;) {
+ /* create table entry */
+ here.bits = (unsigned char)(len - drop);
+-if ((int)(work[sym]) < end) {
++if (work[sym] + 1 < match) {
+ here.op = (unsigned char)0;
+ here.val = work[sym];
+ }
+-else if ((int)(work[sym]) > end) {
+-here.op = (unsigned char)(extra[work[sym]]);
+-here.val = base[work[sym]];
++else if (work[sym] >= match) {
++here.op = (unsigned char)(extra[work[sym] - match]);
++here.val = base[work[sym] - match];
+ }
+ else {
+ here.op = (unsigned char)(32 + 64); /* end of block */
diff -Nru rsync-3.1.3/debian/patches/CVE-2016-9841.patch
rsync-3.1.3/debian/patches/CVE-2016-9841.patch
--- rsync-3.1.3/debian/patches/CVE-2016-9841.patch 1970-01-01
01:00:00.0 +0100
+++ rsync-3.1.3/debian/patches/CVE-2016-9841.patch 2019-03-15
11:25:01.0 +0100
@@ -0,0 +1,224 @@
+>From 9aaec95e82117c1cb0f9624264c3618fc380cecb Mon Sep 17 00:00:00 2001
+From: Mark Adler
+Date: Wed, 21 Sep 2016 22:25:21 -0700
+Subject: [PATCH
Bug#924642: stretch-pu: package rsync/3.1.2-1+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu There are a couple of CVEs that have been fixed by 3.1.2-1+deb9u2. After discussing this with a member of the security team it was not considered important enough to warrant a DSA, but it would be good if it could be included in a point release for stretch. The changelog is: * Apply CVEs from 2016 to the zlib code. closes:#924509 The only change was the addition of 4 patches to the zlib code. The uploaded version was compiled on a stretch system. Thanks! Paul -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.6-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#923860: rsync crashes sporadically when remote host closes connection
On Wed 06 Mar 2019, Timothy Pearson wrote: > On 03/06/2019 05:40 AM, Paul Slootman wrote: > > On Wed 06 Mar 2019, Timothy Pearson wrote: > > > >> Package: rsync > >> Version: 0.9.7-10+b1 > > > > This is either a really ancient version, or a version not related to > > rsync. Please check this. What does 'rsync --version' show? > > > > > > Paul > > Apologies, pasted the wrong version line (librsync). The version is > actually 3.1.3-5; this is an up-to-date Buster system. Wierd, the source line numbers in the backtrace don't match the source. I'll have to investigate. Paul
Bug#923860: rsync crashes sporadically when remote host closes connection
On Wed 06 Mar 2019, Timothy Pearson wrote: > Package: rsync > Version: 0.9.7-10+b1 This is either a really ancient version, or a version not related to rsync. Please check this. What does 'rsync --version' show? Paul
Bug#905764: cups-browsed: restarting always generates log message "Error creating cups notify handler: Could not connect: No such file or directory"
Package: cups-browsed Version: 1.20.4-1 Severity: minor This is basically a fresh install of stable. Every day, after the cups logrotate where cups is restarted, cups-browsed is also restarted by systemd. Upon stopping, cups-browsed generates this log message: cups-browsed[7468]: Error creating cups notify handler: Could not connect: No such file or directory This happened with the stable 1.11.6-3 version, and also with 1.20.4-1 which I tried to see if the problem might have been solved in the meantime. I find it strange that the message only comes when cups-browsed is stopped. I probably don't need cups-browsed in my environment, so I might as well deinstall it, but IMHO it shouldn't be generating such messages without any indication how to fix it. Seeing that avahi-daemon is recommended, I tried installing that and that fixed it. However as it's not a hard dependency, cups-browsed should function without avahi-daemon installed. Thanks, Paul -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-browsed depends on: ii cups-daemon 2.2.1-8+deb9u1 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavahi-glib10.6.32-2 ii libc6 2.24-11+deb9u3 ii libcups2 2.2.1-8+deb9u1 ii libcupsfilters1 1.20.4-1 ii libglib2.0-0 2.50.3-2 ii libldap-2.4-2 2.4.44+dfsg-5+deb9u1 ii lsb-base 9.20161125 Versions of packages cups-browsed recommends: pn avahi-daemon cups-browsed suggests no packages. -- no debconf information
Bug#890236: exim4-daemon-heavy: /usr/sbin/exim4 -bV with log_selector = arguments logs to stderr
On Sun 18 Feb 2018, Andreas Metzler wrote: > > I have rebuilt 4.84.2-2+deb8u1 on sid and did not see a different > behavior. However running exim in a jessie chroot shows the "old" > behavior you described. (stretch does not). So I think this might have > been caused by changes outside exim. I tried to find a copy of 4.89-2 (for amd64) to check whether downgrading again would fix it, but I failed to find that version :( Paul
Bug#890236: exim4-daemon-heavy: /usr/sbin/exim4 -bV with log_selector = arguments logs to stderr
On Mon 12 Feb 2018, Andreas Metzler wrote: > On 2018-02-12 Paul Slootman wrote: > > Package: exim4-daemon-heavy > > Version: 4.90.1-1 > > Severity: normal > > > After upgrading from 4.89-2 to 4.90-1.1 I get a mail from the cron.daily > > run, due to /usr/sbin/exim4 -bV outputting this line to stderr instead > > of to /var/log/exim4/mainlog like it used to: > > > 2018-02-12 11:34:05.084 [29152] cwd=/tmp 2 args: /usr/sbin/exim4 -bV > > > I do have "arguments" included in my log_selector, I find it useful to > > see that, in the mainlog. Apparently something has changed so that it > > now logs to stderr. > > > Please revert to the old behaviour. > > Hello, > I am unable to verify that exim's behavior has changed from 4.89-2 to > 4.90.1-1 in this respect: > ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 > -bV > /dev/null > 2018-02-12 19:02:03 cwd=/tmp/EXIM4 2 args: > exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 -bV > ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 > -bV > /dev/null > 2018-02-12 19:02:17 cwd=/tmp/EXIM4 2 args: > exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 -bV Hmm, I was upgrading a bunch of systems yesterday, it could be that the system with the "arguments" in log_selector was another one, previously running 4.84.2-2+deb8u1. Paul
Bug#890236: exim4-daemon-heavy: /usr/sbin/exim4 -bV with log_selector = arguments logs to stderr
Package: exim4-daemon-heavy Version: 4.90.1-1 Severity: normal After upgrading from 4.89-2 to 4.90-1.1 I get a mail from the cron.daily run, due to /usr/sbin/exim4 -bV outputting this line to stderr instead of to /var/log/exim4/mainlog like it used to: 2018-02-12 11:34:05.084 [29152] cwd=/tmp 2 args: /usr/sbin/exim4 -bV I do have "arguments" included in my log_selector, I find it useful to see that, in the mainlog. Apparently something has changed so that it now logs to stderr. Please revert to the old behaviour. Thanks, Paul -- Package-specific info: Exim version 4.90_1 #2 built 10-Feb-2018 12:45:40 Copyright (c) University of Cambridge, 1995 - 2017 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2017 Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013) Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM DNSSEC Event OCSP PRDR PROXY SOCKS TCP_Fast_Open Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp Fixed never_users: 0 Configure owner: 0:0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.3-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages exim4-daemon-heavy depends on: ii debconf [debconf-2.0] 1.5.61 ii exim4-base 4.90.1-1 ii libc6 2.26-6 ii libdb5.3 5.3.28-12+b1 ii libgnutls303.5.16-1 ii libldap-2.4-2 2.4.45+dfsg-1 ii libmariadbclient18 10.1.28-1 ii libpam0g 1.1.8-3.6 ii libpcre3 2:8.39-3 ii libperl5.265.26.1-4+b1 ii libpq5 9.6.3-3 ii libsasl2-2 2.1.27~101-g0780600+dfsg-3 ii libsqlite3-0 3.16.2-5 exim4-daemon-heavy recommends no packages. exim4-daemon-heavy suggests no packages. -- debconf information: exim4-daemon-heavy/drec:
Bug#887073: libpam-cgfs: spurious "Failed to create a cgroup" messages
Package: libpam-cgfs Version: 2.0.8-1 Severity: normal I have a crontab entry in /etc/cron.d/ to grab a snapshot from a netcam every 2 minutes. About 1-2 times an hour I get a syslog message such as Jan 13 12:44:01 tveer PAM-CGFS[27513]: Failed to create a cgroup for user webcam. Why is this happening? Thanks, Paul -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (700, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-cgfs depends on: ii libc6 2.24-11+deb9u1 ii libfuse22.9.7-1 ii libpam-runtime 1.1.8-3.6 ii libpam0g1.1.8-3.6 ii systemd 232-25+deb9u1 libpam-cgfs recommends no packages. libpam-cgfs suggests no packages. -- no debconf information
Bug#886333: samba: cannot provision a domain: ldb_init_module() complains about gpgme_check_version(1.9.0)
Package: samba Version: 2:4.7.3+dfsg-1 Severity: normal When running "samba-tool domain provision" I get: # samba-tool domain provision Realm [HOME.WURTEL.NET]: WURTEL.NET Domain [WURTEL]: Server Role (dc, member, standalone) [dc]: DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: DNS forwarder IP address (write 'none' to disable forwarding) [172.18.0.2]: Administrator password: Retype password: Looking up IPv4 addresses More than one IPv4 address found. Using 172.18.1.11 Looking up IPv6 addresses More than one IPv6 address found. Using fd2c:2cdd:72b1:0:62e3:27ff:fe05:eec6 ldb_init_module() in ../source4/dsdb/samdb/ldb_modules/password_hash.c version[1.2.2]: gpgme_check_version(1.9.0) not available, gpgme_check_version(NULL) => '1.8.0' ldb: failed to initialise module /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/samba/password_hash.so : Unavailable ldb: failed to initialise module /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/samba : Unavailable ERROR(): uncaught exception - File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run return self.run(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/samba/netcmd/domain.py", line 474, in run nosync=ldap_backend_nosync, ldap_dryrun_mode=ldap_dryrun_mode) File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 2080, in provision schemadn=names.schemadn) File "/usr/lib/python2.7/dist-packages/samba/schema.py", line 82, in __init__ self.ldb = SamDB(global_schema=False, am_rodc=False) As this is the first time I'm trying this, it may well be that I've missed something essential; OTOH I'd expect that when installing from Debian packages that any details are already taken care of. Thanks, Paul -- Package-specific info: * /etc/samba/smb.conf present, and attached * /etc/samba/dhcp.conf present, and attached -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.3-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages samba depends on: ii adduser 3.115 ii dpkg 1.18.24 ii libattr1 1:2.4.47-2+b2 ii libbsd0 0.8.6-2 ii libc6 2.24-17 ii libldb1 2:1.2.2-2 ii libpam-modules1.1.8-3.6 ii libpam-runtime1.1.8-3.6 ii libpopt0 1.16-10+b2 ii libpython2.7 2.7.13-2 ii libtalloc22.1.8-1 ii libtdb1 1.3.11-2 ii libtevent00.9.31-1 ii lsb-base 9.20161125 ii procps2:3.3.12-3 ii python2.7.13-2 ii python-dnspython 1.15.0-1 ii python-samba 2:4.7.3+dfsg-1 ii python2.7 2.7.13-2 ii samba-common 2:4.7.3+dfsg-1 ii samba-common-bin 2:4.7.3+dfsg-1 ii samba-libs2:4.7.3+dfsg-1 ii tdb-tools 1.3.11-2 Versions of packages samba recommends: ii attr1:2.4.47-2+b2 ii logrotate 3.11.0-0.1 ii samba-dsdb-modules 2:4.7.3+dfsg-1 ii samba-vfs-modules 2:4.7.3+dfsg-1 Versions of packages samba suggests: pn bind9 pn bind9utils 1:9.11.2+dfsg-5 pn ctdb pn ldb-tools 2:1.2.2-2 ii ntp1:4.2.8p10+dfsg-3 pn smbldap-tools 0.9.9-1 pn ufw ii winbind2:4.7.3+dfsg-1 -- no debconf information # Global parameters [global] netbios name = WURTEL-WS realm = WURTEL.NET workgroup = WURTEL dns forwarder = 172.18.0.2 server role = active directory domain controller idmap_ldb:use rfc2307 = yes [netlogon] path = /var/lib/samba/sysvol/wurtel.net/scripts read only = No [sysvol] path = /var/lib/samba/sysvol read only = No dhcp.conf Description: inode/empty
Bug#885542: lxcfs: virtualizing the btime field of /proc/stat screws up process start times
Source: lxcfs Version: 2.0.7-1 Severity: normal Tags: upstream As reported here: https://github.com/lxc/lxd/issues/3517 which points to https://github.com/lxc/lxcfs/issues/164 (where is stated that virtualizing the btime field has been reverted due to https://github.com/lxc/lxcfs/issues/189), I'm experiencing wrong stimes for processes. As I find having accurate start times of processes far more important than having an accurate uptime counter for my containers, as do other people as well apparently, I would like to see this reverted until a better solution for the btime field /uptime is found. # lxc-attach -n bla bla# ls -l /run/apache2/apache2.pid -rw-r--r-- 1 root root 5 Dec 27 14:15 /run/apache2/apache2.pid bla# ps -fp `cat /run/apache2/apache2.pid` UIDPID PPID C STIME TTY TIME CMD root 5691 1 0 17:29 ?00:00:01 /usr/sbin/apache2 -k start bla# uptime 21:35:21 up 3 days, 2:57, 0 users, load average: 0.15, 0.13, 0.17 bla# exit host# uptime 21:35:33 up 3 days, 7:00, 5 users, load average: 0.13, 0.13, 0.16 You can see the difference in time between starting the host and the container is the difference between the time shown by ps and the actual start time of the process. Thanks, Paul -- System Information: (reported from a different system as the LXC system has no email as yet)
Bug#880954: rsync: diff for NMU version 3.1.2-2.1
On Thu 14 Dec 2017, Salvatore Bonaccorso wrote: > > I have applied the fixes as well for jessie- and stretch-security. > Would you be able to expose those for additional testing and the > functionality affecting the CVEs? I'm sorry, I don't quite understand what you're asking... If you want to contact the security team for those yourself feel free. thanks again, Paul
Bug#880954: rsync: diff for NMU version 3.1.2-2.1
On Thu 14 Dec 2017, Salvatore Bonaccorso wrote: > > I've prepared an NMU for rsync (versioned as 3.1.2-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. That's fine, thanks for your work. No need for the delay as far as I'm concerned; next week I have some time so then after your NMU is uploaded I can integrate it into my version which has additional fixes. Paul
Bug#866353: rsync: wrong Architecture field in cross built binary package
On Tue 31 Oct 2017, Manuel A. Fernandez Montecelo wrote: > Many packages build-depend on rsync, and this patch seems like a net > gain to apply even in the absence of more benefits. > > What do you think about applying it, Paul? Yes, you're right. I have prepared a new package, however uploading may be delayed a couple of days due to another issue. Please be patient. Thanks for reminding me of this. Paul
Bug#877309: libedit2: editrc manpage again missing
Package: libedit2 Version: 3.1-20170329-1 Severity: normal This is a repeat of bug #612826 which was closed 4 years ago but apparently has been reactivated. Please move the manpage for editrc to the runtime libedit2 package, it's silly to need to install the -dev package for runtime configuration help. Thanks, Paul (trying to be able to enter ë in the mysql client, which worked with libreadline but not now with libedit) -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.3-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init)
Bug#875813: rsync: missed "Number of deleted files"
On Sat 16 Sep 2017, Max wrote: > Ok, the problem happens only with sshdroid (android ssh server application). > With other pc clients everything ok :) > > well, is it a bug of rsync or of sshdroid? You could try using strace on the rsync process to see if it actually does emit the missing line; if so, rsync can hardly be held to blame. It would be a curiously specific error in sshdroid though. Am I to understand that you are running rsync on an android system and connecting to it via this sshdroid? Might it then not be a problem in the rsync running on the android, that it does not pass this info? Please test it yourself with rsync running on debian at both ends, I'm confident that then there it no problem, and hence there's nothing Debian can do to fix this. Paul
Bug#875813: rsync: missed "Number of deleted files"
On Thu 14 Sep 2017, Max wrote: > no errors or warning :/ > > which version of rsync you used? > seems that the problem is with Debian old stable My versions are basically the same as yours: base-files 10 init-system-helpers 1.49 libacl1:amd64 2.2.52-3+b1 libattr1:amd64 1:2.4.47-2+b2 libattr1:i386 1:2.4.47-2+b2 libc6:amd64 2.24-17 libc6:i386 2.24-17 libpopt0:amd64 1.16-10+b2 lsb-base9.20161125 openssh-client 1:7.5p1-10 openssh-server 1:7.5p1-10 rsync 3.1.2-2 sshpass 1.06-1 Paul
Bug#875813: rsync: missed "Number of deleted files"
On Thu 14 Sep 2017, Max wrote: > > sshpass -p $PASS rsync --timeout=30 --bwlimit=$SPEED --log-file=$LOGFILE > --stats --delete --size-only -vrz "/data" -e ssh root@$IP:data/ 2> > /tmp/rsync-error >> $EXTLOG > > cat $EXTLOG > > Number of files: 1 (dir: 1) > Number of created files: 0 > Number of regular files transferred: 0 > Total file size: 0 bytes > Total transferred file size: 0 bytes > Literal data: 0 bytes > Matched data: 0 bytes > File list size: 35 > File list generation time: 0.001 seconds > File list transfer time: 0.000 seconds > Total bytes sent: 74 > Total bytes received: 53 > > sent 74 bytes received 53 bytes 254.00 bytes/sec > total size is 0 speedup is 0.00 Thanks. Unfortunately I still cannot reproduce this: $ mkdir /tmp/data $ sshpass -p $PASS rsync --timeout=30 --bwlimit=10 --log-file=/tmp/rsync-log --stats --delete --size-only -vrz /tmp/data -e ssh root@localhost:data/ 2> /tmp/rsync-error >> /tmp/rsync-stdout $ cat /tmp/rsync-stdout sending incremental file list created directory data data/ Number of files: 1 (dir: 1) Number of created files: 1 (dir: 1) Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 55 Total bytes received: 54 sent 55 bytes received 54 bytes 72.67 bytes/sec total size is 0 speedup is 0.00 Rerunning the command (to match your output of the directory already being created) gives: Number of files: 1 (dir: 1) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 0 bytes Total transferred file size: 0 bytes Literal data: 0 bytes Matched data: 0 bytes File list size: 0 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 52 Total bytes received: 28 sent 52 bytes received 28 bytes 160.00 bytes/sec total size is 0 speedup is 0.00 Does the stderr or the log-file contain anything relevant? Paul
Bug#875813: rsync: missed "Number of deleted files"
On Thu 14 Sep 2017, Max wrote: > > Please try to show *exact* commands with the corresponding output. > > sshpass -p password rsync -vrz /mnt/data0 -e ssh user@ip:data0 > Number of files: 1 (dir: 1) > Number of created files: 0 > Number of regular files transferred: 0 > Total file size: 0 bytes > Total transferred file size: 0 bytes > Literal data: 0 bytes > Matched data: 0 bytes > File list size: 35 > File list generation time: 0.001 seconds > File list transfer time: 0.000 seconds > Total bytes sent: 74 > Total bytes received: 53 This output is only shown if you use --stats, so again: please try to give a script that reproduces the problem. thanks, Paul
Bug#875813: rsync: missed "Number of deleted files"
Hi, On Thu 14 Sep 2017, max wrote: > Package: rsync > Version: 3.1.2-2 > Severity: normal > > Dear Maintainer, > > I using sshpass -p password rsync -vrz source1 source2 -e ssh user@ip:dest > > works but in the output of rsync "Number of deleted files:" is missed > > using rsync in tradition way: rsync source dest the output is correct Please try to show *exact* commands with the corresponding output. Best case scenario is if you could present a script that reproduces the problem so that it takes the guesswork out of the equation for me. Thanks Paul
Bug#848671: xpdf: Many errors "Config Error: Unknown config file command..."
> The suggested Workaround of adding "include /etc/xpdf/includes" > is not helpful as this line is already at the end of the > /etc/xpdf/xpdfrc file in the stock Debian Stretch release :( Actually, at this time the fix is to actually REMOVE that line. That works for English-speaking (and other european) locales, but might suck for those using japanse, thai, etc. Paul
Bug#849765: reportbug: produces invalid mails when there are long lines
I was bitten by the same problem while reporting a bug on mutt, there the problem was the C compiler settings listed (I wonder why including those is useful, those aren't specific to my environment?) It really sucked that after taking 15 minutes to craft a good bug report that due to this silly problem that time was completely wasted because of the stupid exim handling of these too long lines. Perhaps an option to always save a local copy before sending? Paul
Bug#869963: mutt: header_cache location is wrong
Package: mutt
Version: 1.8.3+neomutt20170609-2+b1
Severity: normal
3.96. header_cache
Type: path
Default: (empty)
This variable points to the header cache database. If pointing to a directory
Mutt will contain a header cache database file per folder, if pointing to a
file that file will be a single global header cache. By default it is unset so
no header caching will be used.
---
This is partly true; when specifying a directory, the value of $HOME/Mail
is appended to it, which frankly is quite insane.
With these settings:
set message_cachedir=~/Mail-a
set header_cache=~/Mail-b
and no other setting that contains "Mail", the header cache ends
up being written to
/home/paul/Mail-b/home/paul/Mail/imaps:p.sloot...@example.com@192.168.1.90/INBOX.hcache
The message cache is correctly written to
/home/paul/Mail-a/imaps:p.sloot...@example.com@192.168.1.90/INBOX/*
It seems that constructing the path for the header cache messes up
somewhere by always appending $HOME/Mail/ . This should be fixed.
I used Mail-a and Mail-b in the above settings instead of the original
Mail I had to determine whether message_cachedir was being appended to
the header_cache path, but apparently it's not.
thanks,
Paul
-- Package-specific info:
NeoMutt 20170609 (1.8.3)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 4.11.3-wurtel-ws (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.4.0 20170704 (Debian 6.4.0-1)
Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr'
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man'
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var'
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu'
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode'
'--disable-dependency-tracking' '--with-mailpath=/var/mail'
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache'
'--enable-gpgme' '--enable-lua' '--enable-imap' '--enable-smtp' '--enable-pop'
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--enable-notmuch'
'--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn'
'--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb'
'--without-qdbm' '--with-tokyocabinet' 'build_alias=x86_64-linux-gnu'
'CFLAGS=-g -O2
-fdebug-prefix-map=/build/mutt-PiaMLU/mutt-1.8.3+neomutt20170609=.
-fstack-protector-strong -Wformat -Werror=format-security'
'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2
-fdebug-prefix-map=/build/mutt-PiaMLU/mutt-1.8.3+neomutt20170609=.
-fstack-protector-strong -Wformat -Werror=format-security
-fno-delete-null-pointer-checks
Compile options:
+attach_headers_color +bkgdset +color +compose_to_sender +compress +cond_date
+curs_set +debug +dotlock +encrypt_to_self -exact_address +fcntl -flock
-fmemopen +forgotten_attachments +forwref +futimens +getaddrinfo +getsid
+gnutls +gpgme +gss +hcache -homespool -iconv_nontrans +ifdef +imap
+index_color +initials +keywords +libidn +limit_current_thread +lmdb
-locales_hack +lua +meta +mixmaster +multiple_fcc +nested_if +new_mail +nls
+nntp +notmuch -openssl +pgp +pop +progress +quasi_delete +regcomp
+reply_with_xorig +resizeterm +sasl +sensible_browser -setgi
Bug#865979: at: patch for adding -s option to silence standard messages
Package: at
Version: 3.1.20-3
Severity: wishlist
Tags: patch
I use at from cronjobs (I can't use cron directly because the cronjob
calculates the time according to sunrise / sunset). I think it's silly
that at always outputs two lines to stderr and that there's no way to
prevent this; I don't need to know the job number and that the script
will be run using /bin/sh, thank you very much; I know that by now.
I've added an option -s for silent that suppresses these two output
lines. Please consider adding this to the official build.
Thanks,
Paul Slootman
-- System Information:
Debian Release: 9.0
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.11.3-wurtel-ws (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages at depends on:
ii init-system-helpers 1.48
ii libc62.24-11
ii libpam-runtime 1.1.8-3.6
ii libpam0g 1.1.8-3.6
ii libselinux1 2.6-3+b1
ii lsb-base 9.20161125
Versions of packages at recommends:
ii exim4-daemon-heavy [mail-transport-agent] 4.89-2
at suggests no packages.
-- Configuration Files:
/etc/at.deny [Errno 13] Permission denied: '/etc/at.deny'
-- no debconf information
diff -ru --unidirectional-new-file at-3.1.20.orig/debian/changelog
at-3.1.20/debian/changelog
--- at-3.1.20.orig/debian/changelog 2016-12-08 20:21:58.0 +0100
+++ at-3.1.20/debian/changelog 2017-06-26 11:17:47.865773878 +0200
@@ -1,3 +1,10 @@
+at (3.1.20-3.1) UNRELEASED; urgency=medium
+
+ * Added option -s for silencing at when creating jobs, ie. don't warn
+about the shell and don't show the job ID.
+
+ -- Paul Slootman Mon, 26 Jun 2017 11:06:21 +0200
+
at (3.1.20-3) unstable; urgency=medium
* New version, because the previous one was tagged in error and remote
diff -ru --unidirectional-new-file
at-3.1.20.orig/debian/patches/99-silent-option
at-3.1.20/debian/patches/99-silent-option
--- at-3.1.20.orig/debian/patches/99-silent-option 1970-01-01
01:00:00.0 +0100
+++ at-3.1.20/debian/patches/99-silent-option 2017-06-26 11:22:32.977802011
+0200
@@ -0,0 +1,102 @@
+diff -ru at-3.1.20.orig/at.1.in at-3.1.20/at.1.in
+--- at-3.1.20.orig/at.1.in 2015-12-18 21:29:24.0 +0100
at-3.1.20/at.1.in 2017-06-26 11:15:32.883058668 +0200
+@@ -8,7 +8,7 @@
+ .IR queue ]
+ .RB [ -f
+ .IR file ]
+-.RB [ -mMlv ]
++.RB [ -mMlvs ]
+ .IR timespec ...
+ .br
+ .B at
+@@ -17,7 +17,7 @@
+ .IR queue ]
+ .RB [ -f
+ .IR file ]
+-.RB [ -mMkv ]
++.RB [ -mMkvs ]
+ .RB [ -t
+ .IR time ]
+ .br
+@@ -257,6 +257,9 @@
+ .P
+ Times displayed will be in the format "Thu Feb 20 14:50:00 1997".
+ .TP
++.B \-s
++Be silent; don't output "job xx at xxx" or "warning: commands will be
executed using /bin/sh" messages when jobs are created.
++.TP
+ .B
+ \-c
+ cats the jobs listed on the command line to standard output.
+diff -ru at-3.1.20.orig/at.c at-3.1.20/at.c
+--- at-3.1.20.orig/at.c2016-06-28 22:18:00.0 +0200
at-3.1.20/at.c 2017-06-26 11:15:25.773091230 +0200
+@@ -116,6 +116,7 @@
+ "TERM", "DISPLAY", "_", "SHELLOPTS", "BASH_VERSINFO", "EUID", "GROUPS",
"PPID", "UID"
+ };
+ static int send_mail = 0;
++static int silent = 0;
+
+ /* External variables */
+
+@@ -512,10 +513,12 @@
+
+ close(fd2);
+
+-runtime = localtime(&runtimer);
++if (!silent) {
++ runtime = localtime(&runtimer);
+
+-strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
+-fprintf(stderr, "job %ld at %s\n", jobno, timestr);
++ strftime(timestr, TIMESIZE, TIMEFORMAT_POSIX, runtime);
++ fprintf(stderr, "job %ld at %s\n", jobno, timestr);
++}
+
+ /* Signal atd, if present. Usual precautions taken... */
+ fd = open(PIDFILE, O_RDONLY);
+@@ -749,7 +752,7 @@
+ char *pgm;
+
+ int program = AT; /* our default program */
+-char *options = "q:f:MmbvlrdhVct:"; /* default options for at */
++char *options = "q:f:MmbvlrdhVct:s"; /* default options for at */
+ int disp_version = 0;
+ time_t timer = 0;
+ struct passwd *pwe;
+@@ -864,6 +867,10 @@
+ timer -= timer % 60;
+ break;
+
++ case 's':
++ silent = 1;
++ break;
++
+ default:
+ usage();
+ break;
+@@ -946,7 +953,9 @@
+ It also alows a warning diagnostic to be printed. Because of the
+ possible variance, we always output the diagnostic. */
+
+- fprintf(stderr, "warning: commands will be
Bug#862899: rsync: insufficient escaping/quoting of arguments
On Thu 18 May 2017, Thorsten Glaser wrote: > Now run this: > > remote$ touch ./-zT.mp4 > local$ mkdir test > local$ cd test > local$ rsync -zavPH --numeric-ids -S --stats '--rsh=ssh -T' $remote:\*4 . > > Expected: the “-zT.mp4” file is transferred. > > Actual: the whole home directory of $remote, including subdirectories > and everything, is transferred. Please try again with the --protect-args option, which is meant for such situations. BTW, why specify '--rsh=ssh -T', what's wrong with the default? Paul
Bug#858351: ntpq: if connection to IPv6 address fails, retry with IPv4 address
Package: ntp Version: 1:4.2.8p9+dfsg-2.1 Severity: wishlist If ntpq tries to contact localhost via IPv6, and that fails because ntpd isn't listening there, it doesn't try the IPv4 localhost address. It would be great if it did try that. This may also be seen as a documentation bug report, apparently running ntpd with -4 option (which according to the manpage only affects DNS name resolution) also prevents ntpd listening to ::1, and ntpq tries to connect to ::1 port 123 and fails. The problem is that I don't have IPv6 connectivity with the internet, so ntpq resolves IPv6 addresses and tries to connect to them. I thought that passing -4 would solve this, but apparently not just the resolving is affected, all IPv6 processing is disabled. Maybe split these two aspects of IPv6 into separate options? Thanks, Paul -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.9-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages ntp depends on: ii adduser3.115 ii dpkg 1.18.22 ii libc6 2.24-9 ii libcap21:2.25-1 ii libedit2 3.1-20160903-3 ii libopts25 1:5.18.12-3 ii libssl1.1 1.1.0d-2 ii lsb-base 9.20161125 ii netbase5.4 Versions of packages ntp recommends: pn perl:any Versions of packages ntp suggests: pn ntp-doc -- no debconf information
Bug#858349: ntpq: ctrl-D doesn't stop interactive session anymore
Package: ntp Version: 1:4.2.8p9+dfsg-2.1 Severity: important Control: notfound -1 1:4.2.6.p5+dfsg-7+deb8u2 After upgrading from 1:4.2.6.p5+dfsg-7+deb8u2 I noticed that I can't exit ntpq anymore by sending EOF (ctrl-D). I need to hit ctrl-C twice. Also, this sends CPU usage to 100%: echo rl | ntpq I can't stop this with ctrl-C, I needed to use ctrl-\ . I can't imagine that this serves any purpose, so it would be great if EOF worked again. Thanks, Paul -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.9-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages ntp depends on: ii adduser3.115 ii dpkg 1.18.22 ii libc6 2.24-9 ii libcap21:2.25-1 ii libedit2 3.1-20160903-3 ii libopts25 1:5.18.12-3 ii libssl1.1 1.1.0d-2 ii lsb-base 9.20161125 ii netbase5.4 Versions of packages ntp recommends: pn perl:any Versions of packages ntp suggests: pn ntp-doc -- no debconf information
Bug#856273: vim: explain how the various vimrc files are processed
Thanks for your quick response. On Mon 27 Feb 2017, James McCoy wrote: > On Mon, Feb 27, 2017 at 12:19:40PM +0100, Paul Slootman wrote: > > On a new installation of stretch, I was being frustrated by vim > > hijacking the mouse from xterm (so pasting text ended up quite > > differently than I was expecting). I figured out I needed to disable > > the mouse support in vim, so I created /etc/vim/vimrc.local and put > > set mouse= > > in there. > Did the information in NEWS.Debian.gz (which should have been presented > by apt-listchanges) not help? Actually, no, because I only encountered the problem on the newly-installed system, i.e. no old version was installed so no changes to be listed. On my regular pc I've gone back and had a look at all the listchanges mail I received when I upgraded everything a couple of weeks ago, and this notice was number 38 out of a total of 52 changes listed; so I think it's excusable that I didn't read everything :-) If I had encountered strange behaviour on my regular pc I might have looked over these changes and found this information, however, as I said, everything was just fine there because I've had a vimrc since about 1996... > > However, the mouse was STILL being hijacked, and ":set mouse" showed > > that the setting in /etc/vim/vimrc.local was apparently being ignored. > > Via strace I discovered > > A simpler approach would be to look at the output of ":scriptnames". Strace is my go-to tool for finding out what a process does... You of course have to know about :scriptnames, which now I do, thanks. I stopped actively following vim development around 1999 when I stopped maintaining the OS/2 port :) > > that defaults.vim was being read AFTER > > /etc/vim/vimrc.local was processed, and that overruled the vimrc.local. > > I don't find this logical, I'd expect that anything I put in > > /etc/vim/vimrc.local would be the "default" setting when starting up vim > > and any other fine-tuning can be done via the users' ~/.vimrc . > > Upstream specifically chose to have defaults.vim be loaded _only_ when > the user doesn't have a vimrc file and to leave it up to the sysadminn > to deal with the interaction between defaults.vim and the system vimrc > file. That's why I provided hints in NEWS.Debian about how to deal with > it at the system level. Ok; however IMHO /etc/vim/vimrc.local should come after any "standard" or "default" settings, so I do disagree with first processing vimrc.local and then defaults.vim. So a note in README.Debian would still be very helpful for those who encounter this on newly installed systems, especially as it sounds this is quite Debian-specific. thanks, Paul
Bug#856273: vim: explain how the various vimrc files are processed
Package: vim Version: 2:8.0.0197-2 Severity: wishlist On a new installation of stretch, I was being frustrated by vim hijacking the mouse from xterm (so pasting text ended up quite differently than I was expecting). I figured out I needed to disable the mouse support in vim, so I created /etc/vim/vimrc.local and put set mouse= in there. However, the mouse was STILL being hijacked, and ":set mouse" showed that the setting in /etc/vim/vimrc.local was apparently being ignored. Via strace I discovered that defaults.vim was being read AFTER /etc/vim/vimrc.local was processed, and that overruled the vimrc.local. I don't find this logical, I'd expect that anything I put in /etc/vim/vimrc.local would be the "default" setting when starting up vim and any other fine-tuning can be done via the users' ~/.vimrc . Wierder was that I had upgraded my own system earlier and didn't have problems with the mouse there. After a lot of digging I discovered that if you have a (non-empty!) ~/.vimrc, then the defaults.vim file isn't read. It would be nice if /etc/vim/vimrc.local is read after any and all other system rc files, and before the users' rc files. I couldn't find any documentation about this, it would be nice if some text could be added to README.Debian about these intricacies. Thanks, Paul -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk /usr/bin/vim is /usr/bin/vim.gtk /usr/bin/gvim is /usr/bin/vim.gtk -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.9-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages vim depends on: ii libacl1 2.2.52-3 ii libc62.24-9 ii libgpm2 1.20.4-6.2 ii libselinux1 2.6-3 ii libtinfo56.0+20161126-1 ii vim-common 2:8.0.0197-2 ii vim-runtime 2:8.0.0197-2 vim recommends no packages. Versions of packages vim suggests: ii exuberant-ctags [ctags] 1:5.9~svn20110310-11 pn vim-doc pn vim-scripts -- no debconf information
Bug#856017: lxc: creating unprivileged container as root fails at saving the image cache
Source: lxc Version: 1:2.0.7-1 Severity: normal # lxc-create -n web1 --template download [...] Distribution: debian Release: stretch Architecture: amd64 Downloading the image index Downloading the rootfs Downloading the metadata mkdir: cannot create directory ‘/var/cache/lxc//download/debian/stretch’: Permission denied lxc-create: lxccontainer.c: create_run_template: 1297 container creation template for web1 failed lxc-create: tools/lxc_create.c: main: 318 Error creating container web1 I made a lucky guess and did the following: # chown 820896:820896 /var/cache/lxc/download/debian (820896 is the uid / gid map for root) Now the mkdir etc. succeeded. Apparently changing to the unprivileged IDs happens too early, so that the uid 0 owned /var/cache/lxc/download/debian/ can't be written to. Please fix it so that the chown is not required. Thanks, Paul -- System Information: Debian Release: 8.7 APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lxc depends on: ii init-system-helpers 1.47 ii libapparmor1 2.11.0-2 ii libc62.24-9 ii libcap2 1:2.24-8 ii libgnutls30 3.5.8-3 ii liblxc1 1:2.0.7-1 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii lsb-base 4.1+Debian13+nmu1 ii python3-lxc 1:2.0.7-1 ii python3:amd643.5.3-1 Versions of packages lxc recommends: ii bridge-utils 1.5-9 ii debootstrap 1.0.88 ii dirmngr 1.1.1-5 pn dnsmasq-base ii gnupg 1.4.18-7+deb8u3 ii iptables 1.4.21-2+b1 ii libpam-cgfs 2.0.6-1 ii lxcfs 2.0.6-1 ii openssl 1.0.1t-1+deb8u6 ii rsync 3.1.2-1 ii uidmap1:4.2-3+deb8u1 Versions of packages lxc suggests: pn apparmor pn btrfs-tools ii lvm2 2.02.168-1 -- Configuration Files: /etc/lxc/default.conf changed: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx lxc.id_map = u 0 820896 65536 lxc.id_map = g 0 820896 65536 -- no debconf information
Bug#855856: x11-apps: patch to limit how often xbiff will beep
Package: x11-apps
Version: 7.7+6
Severity: wishlist
Tags: patch
I often get a number of logcheck emails during the first 5 minutes of
the hour from different systems, which have different propagation
times. This leads to xbiff beeping at me every 30s (the default polling
time), which I find a bit excessive.
I had whipped up a patch to make the minimum interval configurable via
an X resource, e.g. in my ~/.Xdefaults file I have the line:
xbiff*beepInterval: 300
which sets the time to 300 seconds.
I had been using this locally. After I recently upgraded to stretch I
noticed that xbiff was beeping too much again, and then remembered the
patch I had made, which was now replaced by a newer version. So I do
miss the patch :)
I've attached the patch.
Since making it (some time ago) I've been wondering whether changing the
pool interval should be the better way of doing it. However, the way
I've done it has been tested extensively :)
Thanks,
Paul
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.9-wurtel-ws (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages x11-apps depends on:
ii libc62.24-9
ii libpng16-16 1.6.28-1
ii libsm6 2:1.2.2-1+b1
ii libx11-6 2:1.6.4-3
ii libxaw7 2:1.0.13-1
ii libxcursor1 1:1.1.14-1+b1
ii libxext6 2:1.3.3-1
ii libxft2 2.3.2-1
ii libxkbfile1 1:1.0.9-2
ii libxmu6 2:1.1.2-2
ii libxmuu1 2:1.1.2-2
ii libxrender1 1:0.9.10-1
ii libxt6 1:1.1.5-1
ii man-db 2.7.6.1-2
Versions of packages x11-apps recommends:
ii xbitmaps 1.1.1-2
Versions of packages x11-apps suggests:
ii mesa-utils 8.3.0-3
-- no debconf information
--- x11-apps-7.7+4/xbiff/Mailbox.c 2013-07-09 17:03:32.0 +0200
+++ x11-apps-7.7+4-mod?/xbiff/Mailbox.c 2015-02-28 12:53:27.223187344 +0100
@@ -53,6 +53,7 @@
#include /* for stat() ** needs types.h ***/
#include /* for printing error messages */
#include
+#include
#ifndef X_NOT_POSIX
#ifdef _POSIX_SOURCE
@@ -142,6 +143,8 @@
offset (volume), XtRString, "33"},
{ XtNonceOnly, XtCBoolean, XtRBoolean, sizeof(Boolean),
offset (once_only), XtRImmediate, (XtPointer)False },
+{ XtNbeepInterval, XtCInterval, XtRInt, sizeof (int),
+ offset (beep_interval), XtRString, "30" },
{ XtNfullPixmap, XtCPixmap, XtRBitmap, sizeof(Pixmap),
offset (full.bitmap), XtRString, "flagup" },
{ XtNfullPixmapMask, XtCPixmapMask, XtRBitmap, sizeof(Pixmap),
@@ -435,6 +438,7 @@
{
long mailboxsize = 0;
Boolean readSinceLastWrite = FALSE;
+static time_t lastbeep = 0;
if (w->mailbox.check_command != NULL) {
waitType wait_status;
@@ -501,8 +505,10 @@
force_redraw = TRUE;
}
} else if (mailboxsize != w->mailbox.last_size) { /* different size */
- if (!w->mailbox.once_only || !w->mailbox.flag_up)
+ if ((!w->mailbox.once_only || !w->mailbox.flag_up) && lastbeep +
w->mailbox.beep_interval < time(NULL)) {
beep(w);
+ lastbeep = time(NULL);
+ }
if (!w->mailbox.flag_up)
force_redraw = w->mailbox.flag_up = TRUE;
}
Bug#838992: mutt: using mutt, will not default to home mail directory: "c", "?" with "set folder" remains in /var/mail
Possibly related: After upgrading to 1.7.2-1 from 1.5.something last weekend, I noticed that hitting 'c' sometimes shows the contents of /var/mail instead of the contents of ~/Mail as it used to. I've since found out that if hitting 'c' and is the first thing you do after starting mutt, the behaviour is like it used to be: repeated tabs switch between showing the subscribed folders and the total contents of ~/Mail. However, if you hit 'c', , 'q', (you didn't see any folders you wanted to change to) and then again hit 'c' and now you see the contents of /var/mail instead?! I.e. the behaviour changes if you abort the 'c' action, which is very unexpected. Paul
Bug#854899: procps: /bin/ps needs /usr/lib/x86_64-linux-gnu/liblz4.so.1 so separate /usr fails
Package: procps Version: 2:3.3.12-3 Severity: normal I just wasted a lot of time figuring out why my newly upgraded-to-testing failed to boot, not assembling my md raid, not detecting my lvm devices, not starting my crypted disks. It boiled down to the udev init.d script using 'ps' to determine whether containers are supported (using a dubious test IMHO but that's beside the point). That failed due to ps not being able to run, so udev wasn't started. I've checked on another system and the ps in procps 2:3.3.9-9 doesn't try to load liblz4.so. I fail to understand why ps would need any compression... Please revert to not using libs from /usr, otherwise /bin/ps might as well move to /usr/bin/ps. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.9-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages procps depends on: ii init-system-helpers 1.47 ii libc62.24-9 ii libncurses5 6.0+20161126-1 ii libncursesw5 6.0+20161126-1 ii libprocps6 2:3.3.12-3 ii libtinfo56.0+20161126-1 ii lsb-base 9.20161125 Versions of packages procps recommends: ii psmisc 22.21-2.1+b1 procps suggests no packages. -- no debconf information
Bug#851911: rsync init script does not load default file options - debian 8.7
On Fri 20 Jan 2017, serwisy wrote: > >>># This file is only used for init.d based systems! > >>># If this system uses systemd, you can specify options etc. for rsync > >>># in daemon mode by copying /lib/systemd/system/rsync.service to > >>># /etc/systemd/system/rsync.service and modifying the copy; add required > >>># options to the ExecStart line. > >>> > >>>That should be self-explanatory. > >>Hey, > >> > >> > >>I don't see these lines: > >> > >># cat rsync > >># defaults file for rsync daemon mode OK, you're right, this was changed so long ago I thought it was already in jessie :) That comment was added in 3.12-1 However, my advice still stands: > >Please do what is suggested by the first comments and see if that > >helps. Paul
Bug#851911: rsync init script does not load default file options - debian 8.7
On Fri 20 Jan 2017, serwisy wrote: > On 01/20/2017 08:13 AM, Paul Slootman wrote: > >On Thu 19 Jan 2017, has...@kontener.eu.org wrote: > >>I've set the RSYNC_OPTS='--port=9500' in /etc/default/rsync but it does not > >>affect daemon options. > >>In Debian 7 all were OK. > >> > >>/etc/default/rsync > >>[..] > >># start rsync in daemon mode from init.d script? > >Can you show the lines that you deleted in [...] ? > > > >You are probably using systemd, and the current /etc/default/rsync as > >distributed has the lines: > > > ># defaults file for rsync daemon mode > ># > ># This file is only used for init.d based systems! > ># If this system uses systemd, you can specify options etc. for rsync > ># in daemon mode by copying /lib/systemd/system/rsync.service to > ># /etc/systemd/system/rsync.service and modifying the copy; add required > ># options to the ExecStart line. > > > >That should be self-explanatory. > Hey, > > > I don't see these lines: > > # cat rsync > # defaults file for rsync daemon mode > > # start rsync in daemon mode from init.d script? Then you probably upgraded from the previous version of rsync and didn't replace /etc/default/rsync when asked by dpkg. You should then have a /etc/default/rsync.dpkg-dist file which is the original (new) version. Please do what is suggested by the first comments and see if that helps. Paul
Bug#851911: rsync init script does not load default file options - debian 8.7
On Thu 19 Jan 2017, has...@kontener.eu.org wrote: > > I've set the RSYNC_OPTS='--port=9500' in /etc/default/rsync but it does not > affect daemon options. > In Debian 7 all were OK. > > /etc/default/rsync > [..] > # start rsync in daemon mode from init.d script? Can you show the lines that you deleted in [...] ? You are probably using systemd, and the current /etc/default/rsync as distributed has the lines: # defaults file for rsync daemon mode # # This file is only used for init.d based systems! # If this system uses systemd, you can specify options etc. for rsync # in daemon mode by copying /lib/systemd/system/rsync.service to # /etc/systemd/system/rsync.service and modifying the copy; add required # options to the ExecStart line. That should be self-explanatory. Paul
Bug#849545: mycli: missing dependency?
Package: mycli Version: 1.8.1-1 Severity: normal It fails to start for me: root@wp1:~# mycli Traceback (most recent call last): File "/usr/bin/mycli", line 6, in from pkg_resources import load_entry_point ImportError: No module named 'pkg_resources' root@wp1:~# dpkg -l python3-click python3-configobj python3-crypto python3-prompt-toolkit python3-pygments python3-pymysql python3-sqlparse python3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture Description +++-===-==-==-=== ii python3 3.4.2-2amd64 interactive high-level object-oriented language (default py ii python3-click 6.6-1 allSimple wrapper around optparse for powerful command line ut ii python3-configobj 5.0.6-1allsimple but powerful config file reader and writer for Pytho ii python3-crypto 2.6.1-5+b2 amd64 cryptographic algorithms and protocols for Python 3 ii python3-prompt-toolkit 1.0.9-1alllibrary for building interactive command lines (Python 3) ii python3-pygments2.0.1+dfsg-1.1+deb allsyntax highlighting package written in Python 3 ii python3-pymysql 0.7.9-2all Pure-Python MySQL Driver - Python 3.x ii python3-sqlparse0.2.2-1all non-validating SQL parser for Python 3 This is on a minimal vserver environment. Thanks, Paul Slootman
Bug#832782: #832782 isc-dhcp-common: Description inaccurate
Similarly the description of e.g. isc-dchp-server states: Extra documentation can be found in the package isc-dhcp-common. I was hoping for in-depth documentation e.g. how isc-dhcp-relay can be setup, finding only the manpages for dhcp-eval and dhcp-options. Those could be listed explicitly instead of the above line. thanks, Paul
Bug#834790: strace output available
I can reproduce this.
"aptitude update" shows these errors:
W: http://download.virtualbox.org/virtualbox/debian/dists/wheezy/InRelease:
Signature by key 7B0FAB3A13B907435925D9C954422A4B98AB5139 uses weak digest
algorithm (SHA1)
W: GPG error: http://repos.codelite.org/wx3.0.2/debian wheezy InRelease: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 6856E1DB1AC82609
E: The repository 'http://repos.codelite.org/wx3.0.2/debian wheezy InRelease'
is not signed.
With version 0.8.1-1 I did not get this hang.
The strace output shows looping going on in futex() calls, here's an extract:
26329 futex(0x7f702cc965d4, FUTEX_WAIT_PRIVATE, 141, NULL
26332 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
26332 futex(0x7f702cc965d4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f702cc965d0,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1
26329 <... futex resumed> ) = 0
26329 futex(0x7f702cc96600, FUTEX_WAKE_PRIVATE, 1
26332 <... futex resumed> ) = 0
26329 <... futex resumed> ) = 0
26332 futex(0x7f702cc96264, FUTEX_WAIT_PRIVATE, 53, NULL
26329 futex(0x7f702cc96264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647,
0x7f702cc96238, 54) = 1
26332 <... futex resumed> ) = 0
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1
26329 futex(0x7f702cc965d4, FUTEX_WAIT_PRIVATE, 143, NULL
26332 <... futex resumed> ) = 0
26332 futex(0x7f702cc96264, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 55,
{1476276978, 250952000}, ) = -1 ETIMEDOUT (Connection timed out)
26332 futex(0x7f702cc965d4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f702cc965d0,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
26329 <... futex resumed> ) = 0
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1) = 0
26329 futex(0x7f702cc96600, FUTEX_WAKE_PRIVATE, 1) = 0
26332 futex(0x7f702cc96264, FUTEX_WAIT_PRIVATE, 57, NULL
26329 futex(0x7f702cc96264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647,
0x7f702cc96238, 58) = 1
26332 <... futex resumed> ) = 0
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1
26329 futex(0x7f702cc965d4, FUTEX_WAIT_PRIVATE, 145, NULL
26332 <... futex resumed> ) = 0
26332 futex(0x7f702cc96264, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 59,
{1476276978, 751398000}, ) = -1 ETIMEDOUT (Connection timed out)
26332 futex(0x7f702cc965d4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f702cc965d0,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}
26329 <... futex resumed> ) = 0
26329 futex(0x7f702cc96600, FUTEX_WAIT_PRIVATE, 2, NULL
26332 futex(0x7f702cc96600, FUTEX_WAKE_PRIVATE, 1
26329 <... futex resumed> ) = 0
26332 <... futex resumed> ) = 1
26329 futex(0x7f702cc96600, FUTEX_WAKE_PRIVATE, 1) = 0
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1
26329 futex(0x7f702cc96260, FUTEX_WAIT_PRIVATE, 2, NULL
26332 <... futex resumed> ) = 0
26332 futex(0x7f702cc96260, FUTEX_WAKE_PRIVATE, 1
26329 <... futex resumed> ) = 0
26332 <... futex resumed> ) = 1
26329 futex(0x7f702cc96260, FUTEX_WAKE_PRIVATE, 1
26332 futex(0x7f702cc96264, FUTEX_WAIT_PRIVATE, 61, NULL
26329 <... futex resumed> ) = 0
26332 <... futex resumed> ) = -1 EAGAIN (Resource temporarily
unavailable)
26329 futex(0x7f702cc96264, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647,
0x7f702cc96238, 62
26332 futex(0x7f702cc96238, FUTEX_WAIT_PRIVATE, 2, NULL
26329 <... futex resumed> ) = 0
26329 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1) = 1
26332 <... futex resumed> ) = 0
26329 futex(0x7f702cc965d4, FUTEX_WAIT_PRIVATE, 147, NULL
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1) = 0
26332 futex(0x7f702cc96264, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 63,
{1476276979, 254209000}, ) = -1 ETIMEDOUT (Connection timed out)
26332 futex(0x7f702cc965d4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f702cc965d0,
{FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
26332 futex(0x7f702cc96238, FUTEX_WAKE_PRIVATE, 1
26329 <... futex resumed> ) = 0
26332 <... futex resumed> ) = 0
26329 futex(0x7f702cc96600, FUTEX_WAKE_PRIVATE, 1
26332 futex(0x7f702cc96264, FUTEX_WAIT_PRIVATE, 65, NULL
The complete strace output can be found at
http://corky.wurtel.net/~paul/bug-834790-strace.txt.gz
Paul
Bug#833155: rsync: "rsync root@host:'dat' /" doesn't autocomplete
retitle 833155 bash-completion: "rsync root@host:'dat' /" doesn't autocomplete reassign 833155 bash-completion thanks On Mon 01 Aug 2016, Askar Safin wrote: > The following command does not autocomplete: > rsync root@host:'dat' / > > bash-completion is installed. The following is uncommented in > /etc/bash.bashrc: > if ! shopt -oq posix; then > if [ -f /usr/share/bash-completion/bash_completion ]; then > . /usr/share/bash-completion/bash_completion > elif [ -f /etc/bash_completion ]; then > . /etc/bash_completion > fi > fi > > Completion works normally in other commands, such as dpkg. > "rsync root@host:dat /" works normally. The rsync package does not contain any bash completion files; hence I'm reassigning this bug to the bash-completion package. Thanks, Paul
Bug#833740: munin-plugins-core: nfsd4 plugin should not be configured with only NFS 3 in use
Package: munin-plugins-core Version: 2.0.25-2 Severity: normal The nfsd4 plugin only checks for the existence of the /proc/net/rpc/nfsd file, as does the nfsd (without "4") plugin. This leads to both being configured but with the nfsd4 plugin returning no data for almost all values. Please add this check: --- /usr/share/munin/plugins/nfsd4 2015-08-30 10:09:21.0 +0200 +++ /etc/munin/plugins/nfsd42016-08-08 13:16:48.012407997 +0200 @@ -37,7 +37,7 @@ savefh secinfo setattr setcltid setcltidconf verify write rellockowner" if [ "$1" = "autoconf" ]; then - if [ -f "$NFSD" ]; then + if [ -f "$NFSD" ] && grep -sq proc4ops $NFSD; then echo yes exit 0 else Thanks, Paul -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.3-wurtel (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages munin-plugins-core depends on: ii munin-common 2.0.25-2 ii perl 5.22.2-1 Versions of packages munin-plugins-core recommends: pn libnet-snmp-perl Versions of packages munin-plugins-core suggests: ii conntrack 1:1.4.2-2 pn libcache-cache-perl ii libdbd-mysql-perl 4.033-1+b1 ii libnet-dns-perl 0.81-2+b1 pn libnet-netmask-perl pn libnet-telnet-perl ii libxml-parser-perl 2.44-1+b1 ii python 2.7.9-1 ii ruby1:2.1.5 ii ruby2.1 [ruby-interpreter] 2.1.5-1 -- no debconf information
Bug#832756: xdg-utils: my ssh.desktop config stopped working
Package: xdg-utils
Version: 1.1.1-1
Severity: normal
Tags: patch
I have a file ~/.local/share/applications/ssh.desktop :
--snip
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=SSH
TryExec=rxvt
Exec=/home/paul/bin/ssh-launcher
NoDisplay=false
Comment=SSH launcher
--snip
~/bin/ssh-launcher contains:
--snip
#!/bin/bash
host=${1/ssh:\/\/}
exec rxvt -ls -n $1 -T $1 -e ssh $host
--snip
This is so that I can click on an ssh://ipaddress link on a webpage and
have an rxvt opened to that host. That worked fine prior to upgrading to
this version; 1.1.0~rc1+git20111210-7.3 worked fine; if I use the
xdg-open from that version then it works.
When I run bash -x xdg-open ssh://ipaddress I see:
--snip
+ for x in '`echo "$xdg_user_dir:$xdg_system_dirs" | sed '\''s/:/ /g'\''`'
+ search_desktop_file ssh.desktop /home/paul/.local/share/applications/
ssh://172.101.0.52
+ local default=ssh.desktop
+ local dir=/home/paul/.local/share/applications/
+ local target=ssh://172.101.0.52
+ local file=
+ '[' -r /home/paul/.local/share/applications//ssh.desktop ']'
+ file=/home/paul/.local/share/applications//ssh.desktop
+ '[' -r /home/paul/.local/share/applications//ssh.desktop ']'
++ first_word
++ get_key /home/paul/.local/share/applications//ssh.desktop Exec
++ read first rest
++ local file=/home/paul/.local/share/applications//ssh.desktop
++ local key=Exec
++ local desktop_entry=
++ IFS_='
'
++ IFS=
++ read line
++ case "$line" in
++ desktop_entry=
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ '[' -n '' ']'
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ IFS='
'
++ echo ''
+ command=
++ which
+ command_exec=
++ get_key /home/paul/.local/share/applications//ssh.desktop Icon
++ local file=/home/paul/.local/share/applications//ssh.desktop
++ local key=Icon
++ local desktop_entry=
++ IFS_='
'
++ IFS=
++ read line
++ case "$line" in
++ desktop_entry=
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ IFS='
'
+ icon=
++ get_key /home/paul/.local/share/applications//ssh.desktop Name
++ local file=/home/paul/.local/share/applications//ssh.desktop
++ local key=Name
++ local desktop_entry=
++ IFS_='
'
++ IFS=
++ read line
++ case "$line" in
++ desktop_entry=
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ '[' -n '' ']'
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ IFS='
'
+ localised_name=
++ get_key /home/paul/.local/share/applications//ssh.desktop Exec
++ local file=/home/paul/.local/share/applications//ssh.desktop
++ local key=Exec
++ local desktop_entry=
++ IFS_='
'
++ IFS=
++ read line
++ case "$line" in
++ desktop_entry=
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ '[' -n '' ']'
++ read line
++ case "$line" in
++ read line
++ case "$line" in
++ read line
++ IFS='
'
++ last_word
++ read first rest
++ echo ''
+ set --
+ local args=0
+ local replaced=0
+ '[' 0 -gt 0 ']'
+ '[' 0 -eq 1 ']'
+ set -- ssh://172.101.0.52
+ '' ssh://172.101.0.52
/usr/bin/xdg-open: line 709: : command not found
+ '[' 127 -eq 0 ']'
+ for d in '$dir/*/'
+ '[' -d '/home/paul/.local/share/applications//*/' ']'
+ for x in '`echo "$xdg_user_dir:$xdg_system_dirs" | sed '\''s/:/ /g'\''`'
+ search_desktop_file ssh.desktop /usr/local/share//applications/
ssh://172.101.0.52
+ local default=ssh.desktop
+ local dir=/usr/local/share//applications/
+ local target=ssh://172.101.0.52
+ local file=
+ '[' -r /usr/local/share//applications//ssh.desktop ']'
++ echo ssh.desktop
++ sed -e 's|-|/|'
+ '[' -r /usr/local/share//applications//ssh.desktop ']'
+ '[' -r '' ']'
+ for d in '$dir/*/'
+ '[' -d '/usr/local/share//applications//*/' ']'
+ for x in '`echo "$xdg_user_dir:$xdg_system_dirs" | sed '\''s/:/ /g'\''`'
+ search_desktop_file ssh.desktop /usr/share//applications/ ssh://172.101.0.52
+ local default=ssh.desktop
+ local dir=/usr/share//applications/
+ local target=ssh://172.101.0.52
+ local file=
+ '[' -r /usr/share//applications//ssh.desktop ']'
++ echo ssh.desktop
++ sed -e 's|-|/|'
+ '[' -r /usr/share//applications//ssh.desktop ']'
+ '[' -r '' ']'
+ for d in '$dir/*/'
+ '[' -d /usr/share//applications//screensavers/ ']'
+ search_desktop_file ssh.desktop /usr/share//applications//screensavers/
ssh://172.101.0.52
Bug#805512: usb-modeswitch-data: Huawei 12d1:1446 does not switch due to bad udev rule
On Wed 13 Jan 2016, Josua Dietze wrote:
> I have just released upstream version 2.3.0 of usb_modeswitch and version
> 20160112 of the data package.
>
> The bug with the missing log is fixed, as well as a potentially disruptive
> other bug in the wrapper (see
> http://draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=16240 ).
>
> However, I have not been able to replicate bug #805512 that Blake Miner
> describes.
>
> Unfortunately, there is no way to move forward with this bug until I see the
> usb_modeswitch log with the raw parameter data transmitted by the systemd
> instance.
I had problems with the mode switch not happening with a Huawei E3272.
This was with usb-modswitch 2.2.0+repack0-2 and usb-modeswitch-data
20150115-1. After upgrading to 2.4.0+repack0-1 and 20160612-1 I had no
problems, so updating to this version works for me. I'm using systemd
with basically jessie. I also needed to upgrade libjim0.76 to 0.76-2
due to dependencies but nothing else.
With the old version I needed this line in de rules.d file:
ATTR{idVendor}=="12d1", ATTR{idProduct}=="1f01", RUN +="usb_modeswitch '%b/%k'"
I first thought that the problem was that the catchall rule has ATTRS
while my lins has ATTR... but I admit I know next to nothing about udev
:)
Paul
Bug#813472: debirf: enable use of xz compression
Package: debirf Version: 0.35 Severity: wishlist It would be great if xz was used for the compression of the rootfs file, busybox supports running as unxz or xzcat so it should not be a problem. It will make the initramfs about 35% smaller. I needed to boot from a very small boot medium, and I've worked around it by removing all docs and manpages and unneeded kernel modules, but having a better compression would be much appreciated. Thanks, Paul Slootman -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.1-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages debirf depends on: ii apt 1.2.1 ii cpio 2.11+dfsg-4.1 ii debootstrap 1.0.75 ii fakechroot 2.16-1 ii fakeroot 1.20.2-1 ii klibc-utils 2.0.4-4 Versions of packages debirf recommends: pn grub-common1.99-27+deb7u2 ii lsb-release4.1+Debian13+nmu1 pn xorriso debirf suggests no packages. -- no debconf information
Bug#811012: samba-common: rmdir: failed to remove ‘/etc/dhcp3/dhclient-enter-hooks.d’
Package: samba-common Version: 2:4.1.17+dfsg-2+deb8u1 Severity: important Upon upgrade, the postinst fails with the following message: Setting up samba-common (2:4.1.17+dfsg-2+deb8u1) ... rmdir: failed to remove ‘/etc/dhcp3/dhclient-enter-hooks.d’: No such file or directory dpkg: error processing package samba-common (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of samba-common-bin: samba-common-bin depends on samba-common (= 2:4.1.17+dfsg-2+deb8u1); however: Package samba-common is not configured yet. dpkg: error processing package samba-common-bin (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of samba: samba depends on samba-common (= 2:4.1.17+dfsg-2+deb8u1); however: Package samba-common is not configured yet. samba depends on samba-common-bin (= 2:4.1.17+dfsg-2+deb8u1); however: Package samba-common-bin is not configured yet. dpkg: error processing package samba (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of smbclient: smbclient depends on samba-common (= 2:4.1.17+dfsg-2+deb8u1); however: Package samba-common is not configured yet. dpkg: error processing package smbclient (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: samba-common samba-common-bin samba smbclient E: Sub-process /usr/bin/dpkg returned an error code (1) Adding "|| true" to the "rmdir -p" line helps. Perhaps add some logic to not to try to remove the directory if the parent doesn't exist. Thanks, Paul Slootman -- System Information: Debian Release: jessie Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.1-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages samba-common depends on: ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.26 ii ucf3.0030 Versions of packages samba-common recommends: iU samba-common-bin 2:4.1.17+dfsg-2+deb8u1 samba-common suggests no packages. -- debconf information excluded
Bug#622160: rsync: 65000 hard links => assertion failure
On Sun 10 Apr 2011, Neal H. Walfield wrote:
> I use storebackup to create daily backups and I mirror these backups
> to a report machine using:
>
> rsync --stats -a -z -H --numeric-ids --link-dest=/backup \
> /backup/ bruckner.vpn.huenfield.org:/home/backup/
>
> During today's run, rsync reported the following errors:
>
> ERROR 2011.04.10 11:14:45 27930 rsync: link
> "/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/dvb/s5h1409.h"
> => forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)
> ERROR 2011.04.10 11:14:45 27930 rsync: link
> "/home/backup/forster/2011.04.10_06.36.53/neal/src/temp/linux-2.6-2.6.32/debian/build/build_i386_none_486/include/config/early/printk.h"
> => forster/2011.03.10_11.11.28/.gksu.lock failed: Too many links (31)
> I'd like rsync to not fail. Perhaps it should create an additional
> copy of the content.
On Thu 16 Oct 2014, Jonathan David Amery wrote:
>
>
> It appears that this may have improved slightly since 2011 -- there's
> no longer an assertion failure
>
> My backups do:
>
> rsync --archive --sparse --numeric-ids --compress \
> --fuzzy --hard-links --delete --quiet --one-file-system \
> --link-dest=/mnt/backups/internal/ivanova/aleph/2014-10-15 \
> ivanova:/mnt/aleph/. /mnt/backups/internal/ivanova/aleph/2014-10-16/.
>
> and today I got the error:
>
> rsync: link
> "/mnt/backups/internal/ivanova/aleph/2014-10-16/./home/jdamery/dev/projects/buildit/lis2las/rfid.o"
> => home/jdamery/dev/projects/buildit/addcurve/rfid.o failed: Too many links
> (31)
> When it has this link failure rsync should make a new copy of the file
> exactly as if it had been unable to find a file to link in the first
> place.
In my testing today it seems that this does not go wrong anymore and a
new copy of the file is indeed created; here's the relevant strace
output that shows the link() call failed and subsequently a new file was
created:
[pid 24011] lstat("b", 0x7ffcc58574a0) = -1 ENOENT (No such file or directory)
[pid 24011] lstat("/tmp/d/linkdest/./b", {st_mode=S_IFREG|0644, st_size=9,
...}) = 0
[pid 24011] link("/tmp/d/linkdest/./b", "b") = -1 EMLINK (Too many links)
[pid 24011] open(".b.Tnq0GH", O_RDWR|O_CREAT|O_EXCL, 0600) = 0
[pid 24011] fchmod(0, 0600) = 0
[pid 24011] open("/tmp/d/linkdest/./b", O_RDONLY) = 4
[pid 24011] read(4, "contents\n", 8192) = 9
[pid 24011] write(0, "contents\n", 9) = 9
[pid 24011] read(4, "", 8192) = 0
[pid 24011] close(4)= 0
[pid 24011] close(0)= 0
[pid 24011] lstat(".b.Tnq0GH", {st_mode=S_IFREG|0600, st_size=9, ...}) = 0
[pid 24011] utimensat(AT_FDCWD, ".b.Tnq0GH", {UTIME_NOW, {1451558126,
485533088}}, AT_SYMLINK_NOFOLLOW) = 0
[pid 24011] chmod(".b.Tnq0GH", 0644)= 0
[pid 24011] rename(".b.Tnq0GH", "b")= 0
If you still have problems please reply to the bug report so that I can
investigate further. Otherwise I will close this bug soon.
thanks,
Paul
Bug#583345: auto-detect timestamp resolution
On Thu 27 May 2010, martin f krafft wrote:
>
> It should be possible to use the value of
> pathconf("path/to/destination", _POSIX_TIMESTAMP_RESOLUTION) to
> determine the minimum timestamp resolution and to set
> --modify-window accordingly by default.
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html
>
> Unfortunately, this does not seem to exist in Debian. :(
>
> Maybe in the mean time, rsync chould use statfs(3)'s f_fsid field
> and set --modify-window to a default of 2 for FAT/VFAT destinations?
> I realise this is a hack, but it'd be useful until
> _POSIX_TIMESTAMP_RESOLUTION became available.
The biggest problem with both solutions is that you would have to check
the filesystem / _POSIX_TIMESTAMP_RESOLUTION thing for every directory
you traverse, as there may be FAT filesystems on subdirectories or bind
mounts etc.; this may cause a hefty overhead.
Paul
Bug#670960: wishlist: make a sound with -beep when complete
tag 670960 +wontfix thanks On Mon 30 Apr 2012, Ubuntu6226 wrote: > > another wishlist... for long processes, would be cool to add: > > --beep > > and ~/.rsync.rc with into > > beep = aplay ~/mysound.wav This is something that can trivially be solved by using a wrapper script that calls the original rsync binary and then plays the beep; so this won't be added to the rsync binary itself, sorry. E.g. put this in /usr/local/bin/rsync and ensure /usr/local/bin is first in your PATH envrionment variable: #!/bin/sh /usr/bin/rsync "$@" rc=$? aplay $HOME/mysound.wav exit $rc You could even play different sounds depending on the exit status of rsync... Paul
Bug#809410: debirf: chroot error / fakechroot segfault
On Wed 30 Dec 2015, Paul Slootman wrote: > Downgrading fakechroot to 2.16-1 gives a working configuration on my > work system, ... If I specify DEBIRF_SUITE=jessie in debirf.conf, I get this: run-parts: executing rescue/modules/a0_prep-root dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied passwd: password expiry information changed. apt-get: symbol lookup error: apt-get: undefined symbol: _Z18DisplayFileInPagerRKSs run-parts: rescue/modules/a0_prep-root exited with return code 127 Paul
Bug#809410: debirf: chroot error / fakechroot segfault
Downgrading fakechroot to 2.16-1 gives a working configuration on my work system, at home I get a different error: run-parts: executing rescue/modules/install-kernel E: No packages found Reading package lists... Done Building dependency tree... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. extracting kernel package linux-image-*... dpkg-deb: error: failed to read archive '/var/cache/apt/archives/linux-image-*': No such file or directory run-parts: rescue/modules/install-kernel exited with return code 2 Is this because I use a self-compiled kernel? How to override? thanks, Paul
Bug#809410: debirf: chroot error / fakechroot segfault
Package: debirf Version: 0.35 Severity: important I first tried this on my work system which is basically jessie without systemd and some packages from testing and unstable: $ cd ~/tmp $ mkdir debirf $ cd debirf $ tar xzf /usr/share/doc/debirf/example-profiles/rescue.tgz $ debirf make rescue debirf> loading profile 'rescue'... debirf> creating debirf root... debirf> distro/suite: debian/sid dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010) [... deletia ...] run-parts: executing rescue/modules/a0_prep-root dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied /usr/sbin/chroot: /home/paul/tmp/rescue/root/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so) /usr/sbin/chroot: /home/paul/tmp/rescue/root/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so) run-parts: rescue/modules/a0_prep-root exited with return code 1 I then tried the exact same thing at home, which is basically testing although not updated for a while, again no systemd: $ cd ~/tmp $ mkdir debirf $ cd debirf $ tar xzf /usr/share/doc/debirf/example-profiles/rescue.tgz $ debirf make rescue [... deletia ...] run-parts: executing rescue/modules/a0_prep-root dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for reading: Permission denied /usr/bin/env.fakechroot: line 137: 16472 Segmentation fault $fakechroot_env_cmd "$@" run-parts: rescue/modules/a0_prep-root exited with return code 139 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.1-wurtel-ws (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages debirf depends on: ii apt 1.1.10 (1.0.10 on my work system) ii cpio 2.11+dfsg-4.1 ii debootstrap 1.0.75 ii fakechroot 2.18-1 ii fakeroot 1.20.2-1 ii klibc-utils 2.0.4-4 Versions of packages debirf recommends: ii grub-common 1.99-14 ii lsb-release 4.1+Debian13+nmu1 pn xorriso debirf suggests no packages. -- no debconf information
