Bug#796899: Acknowledgement (interesting segfault)
By comparing stack traces under ld-linux.so and not, I was able to determine
that the NULL is coming from global->errors, which is supposed to get
initialized to STDERR but somehow isn't when ld-linux.so runs curl.
While playing with that, I noticed that trying to printf the address of global
causes a segfault, too. Here's a minimal test case for that, which
replaces src/tool_main.c in curl's source tree.
#include
#include
int main(int argc, char *argv[])
{
FILE *global=0;
printf("STARTED\n");
printf("GLOBAL %p\n", global);
}
joey@kite:~/tmp/curl-7.44.0/debian/build>./src/.libs/curl
STARTED
GLOBAL (nil)
joey@kite:~/tmp/curl-7.44.0/debian/build>/lib64/ld-linux-x86-64.so.2
./src/.libs/curl
STARTED
Segmentation fault
(Building this same code manually, not in curl's source tree, I have not been
able to reproduce the problem. Something about how it's linked as part of
curl is contributing.)
Here's an even more minimal and strange test case!
joey@kite:~/tmp/curl-7.44.0/debian/build>cat src/tool_main.c
#include
#include
int main(int argc, char *argv[])
{
fprintf(stdout, "HELLO\n");
}
joey@kite:~/tmp/curl-7.44.0/debian/build>./src/.libs/curl
HELLO
joey@kite:~/tmp/curl-7.44.0/debian/build>/lib64/ld-linux-x86-64.so.2
./src/.libs/curl
Segmentation fault
--
see shy jo
signature.asc
Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
> int main(int argc, char *argv[])
> {
> fprintf(stdout, "HELLO\n");
> }
Even fdopen(1, 'w') crashes the same way. Maybe whatever initialization
is needed for the stream functions to work isn't happening under
ld-linux.so.
--
see shy jo
signature.asc
Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
Joey Hess wrote:
> Even fdopen(1, 'w') crashes the same way.
Er, ignore that, it's obviously wrong.
But, stdout stderr etc are indeed looking very wrong..
joey@kite:~/tmp/curl-7.44.0/debian/build>cat src/tool_main.c
#include
#include
int main(int argc, char *argv[])
{
fprintf(stdout, "hello\n");
}
joey@kite:~/tmp/curl-7.44.0/debian/build>gdb /lib64/ld-linux-x86-64.so.2
(gdb) b __GI__IO_fwrite
Breakpoint 1 at 0x773d0a30: file iofwrite.c, line 35.
(gdb) r ./src/.libs/curl
Starting program: /lib64/ld-linux-x86-64.so.2 ./src/.libs/curl
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, __GI__IO_fwrite (buf=0x77df362b, size=1, count=6,
fp=0x0) at iofwrite.c:35
^^^ stdout
--
see shy jo
signature.asc
Description: Digital signature
Bug#796899: easy as -pie
Fully minimal test case is in the attached shell script. This bug only occurs if the binary is linked with -pie. -- see shy jo testcase.sh Description: Bourne shell script signature.asc Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
Joey Hess wrote:
> Tried building curl from source to get a useful backtrace, but that
> build didn't have the problem.
>
> Since that build was done using gcc 4.9.2-4, it may be another hint in
> the direction of the recent gcc transitions.
Indeed, I built curl with gcc 5.2.1-4 and it has the problem.
So, the gcc upgrade led to this problem.
Here is the backtrace:
joey@kite:~/tmp/curl-7.44.0/debian>LD_LIBRARY_PATH=./build/lib/.libs/ gdb
/lib64/ld-linux-x86-64.so.2
GNU gdb (Debian 7.10-1) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
(gdb) run ./build/src/.libs/curl
Starting program: /lib64/ld-linux-x86-64.so.2 ./build/src/.libs/curl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
fputc (c=99, fp=0x0) at fputc.c:37
37 fputc.c: No such file or directory.
(gdb) bt
#0 fputc (c=99, fp=0x0) at fputc.c:37
#1 0x77b7cd9f in dprintf_formatf (data=,
stream=0x773d7470 , format=,
ap_save=ap_save@entry=0x7fffe060) at mprintf.c:616
#2 0x77b7e58e in curl_mfprintf (whereto=,
format=) at mprintf.c:1121
#3 0x77ddae51 in ?? ()
#4 0x in ?? ()
The code here is quite horrible, kind of looks like the FILE * has
been somehow optimised out, perhaps wrongly?
static int dprintf_formatf(
void *data, /* untouched by format(), just sent to the stream() function in
the second argument */
/* function pointer called for each output character */
int (*stream)(int, FILE *),
OUTCHAR(*f);
#define OUTCHAR(x) \
do{ \
if(stream((unsigned char)(x), (FILE *)data) != -1) \
done++; \
else \
return done; /* return immediately on failure */ \
} WHILE_FALSE
--
see shy jo
signature.asc
Description: Digital signature
Bug#797813: remove recommends for old deprecations
Package: perl-modules Version: 5.20.2-6 Severity: normal Installing linux-image-amd64 currently results in this: The following extra packages will be installed: busybox firmware-linux-free initramfs-tools irqbalance klibc-utils libalgorithm-c3-perl libarchive-extract-perl libb-hooks-endofscope-perl libb-hooks-op-check-perl libbareword-filehandles-perl libcap-ng0 libcgi-fast-perl libcgi-pm-perl libclass-c3-perl libclass-c3-xs-perl libclass-method-modifiers-perl libclass-xsaccessor-perl libcpan-changes-perl libcpan-meta-perl libdata-optlist-perl libdata-perl-perl libdata-section-perl libdevel-caller-perl libdevel-globaldestruction-perl libdevel-lexalias-perl libencode-locale-perl libexporter-tiny-perl libfcgi-perl libfile-slurp-perl libgetopt-long-descriptive-perl libglib2.0-0 libglib2.0-data libhtml-parser-perl libhtml-tagset-perl libhttp-date-perl libhttp-message-perl libimport-into-perl libindirect-perl libio-html-perl libio-stringy-perl libklibc liblexical-sealrequirehints-perl liblist-moreutils-perl liblog-message-perl liblog-message-simple-perl liblwp-mediatypes-perl libmodule-build-perl libmodule-implementation-perl libmodule-pluggable-perl libmodule-runtime-perl libmodule-signature-perl libmoo-perl libmoox-handlesvia-perl libmro-compat-perl libmultidimensional-perl libnamespace-autoclean-perl libnamespace-clean-perl libnuma1 libpackage-constants-perl libpackage-stash-perl libpackage-stash-xs-perl libpadwalker-perl libparams-classify-perl libparams-util-perl libparams-validate-perl libpath-tiny-perl libpod-latex-perl libpod-markdown-perl libpod-readme-perl librole-tiny-perl libsoftware-license-perl libstrictures-perl libsub-exporter-perl libsub-exporter-progressive-perl libsub-identify-perl libsub-install-perl libsub-name-perl libterm-ui-perl libtext-soundex-perl libtext-template-perl libtimedate-perl libtry-tiny-perl libtype-tiny-perl libtype-tiny-xs-perl libunicode-utf8-perl liburi-perl libvariable-magic-perl libxml2 linux-base linux-image-4.1.0-2-amd64 perl perl-modules rename sgml-base shared-mime-info xdg-user-dirs xml-core Rather a lot of this mess is modules that perl-modules recommends because they were removed from it. Since this happened some time (and over a release) ago, removing those recommends would decrease bloat. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages perl-modules depends on: ii dpkg 1.18.1 ii perl-base 5.20.2-6 Versions of packages perl-modules recommends: ii libarchive-extract-perl0.74-1 ii libcgi-pm-perl 4.21-1 ii libmodule-build-perl 0.421400-1 ii libmodule-pluggable-perl 5.1-2 ii libpackage-constants-perl 0.04-1 ii libpod-latex-perl 0.61-2 ii libterm-ui-perl0.46-1 ii libtext-soundex-perl 3.4-1+b2 ii perl 5.20.2-6 Versions of packages perl-modules suggests: pn libb-lint-perl pn libcpanplus-dist-build-perl pn libcpanplus-perl pn libfile-checktree-perl ii liblog-message-perl 0.8-1 ii liblog-message-simple-perl 0.10-2 pn libobject-accessor-perl -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#797588: brightness up/down keys super laggy with kernel 4.0.0
Package: xfce4-power-manager Version: 1.4.4-4 Severity: normal Pressing my laptop's keys to increase/decrease brightness is nearly compltely broken after upgrade from kernel 3.16.0 to 4.0.0. Hardware is a Lenovo Yoga 11gs. The display brightness slider in the panel works perfectly fine; brightness adjusts smoothly and quickly. However, if I press eg, the key to redice brightness, there's a lag of 1 to 3 seconds before my keypresses take effect. This makes it very hard to get to the desired brightness. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-power-manager depends on: ii libc6 2.19-19 ii libcairo2 1.14.2-2 ii libdbus-1-3 1.8.20-1 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-02.31.5-1 ii libglib2.0-0 2.44.1-1.1 ii libgtk2.0-0 2.24.28-1 ii libnotify40.7.6-2 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libupower-glib3 0.99.3-1+b2 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxfce4ui-1-04.12.1-2 ii libxfce4util7 4.12.1-2 ii libxfconf-0-2 4.12.0-2+b1 ii libxrandr22:1.5.0-1 ii upower0.99.3-1+b2 ii xfce4-power-manager-data 1.4.4-4 Versions of packages xfce4-power-manager recommends: ii libpam-systemd 225-1 ii xfce4-power-manager-plugins 1.4.4-4 xfce4-power-manager suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#724610: corruption bug seen again
We've seen this bug again, with version 1.2.19.0-1. -- see shy jo signature.asc Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
Aurelien Jarno wrote: The fp pointer is NULL in both of the above functions. Could you please try to get a backtrace to see which caller starts to pass a NULL pointer? Tried building curl from source to get a useful backtrace, but that build didn't have the problem. Since that build was done using gcc 4.9.2-4, it may be another hint in the direction of the recent gcc transitions. -- see shy jo signature.asc Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
Colin Watson wrote: Here's LD_DEBUG=all output, which suggests it might relate to NSS. 22014: symbol=fclose; lookup in file=/lib/x86_64-linux-gnu/libc.so.6 [0] 22014: binding file /lib/x86_64-linux-gnu/libnss_compat.so.2 [0] to /lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `fclose' [GLIBC_2.2.5] strace shows curl gets as far as reading ~/.curlrc before crashing, while ssh seems to start running and reads /etc/passwd before crashing. gdb shows ssh and curl crashing in fwrite and fputc, respectively. Starting program: /lib64/ld-linux-x86-64.so.2 /usr/bin/ssh [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. __GI__IO_fwrite (buf=0x77db4a00, size=1, count=525, fp=0x0) at iofwrite.c:41 41 iofwrite.c: No such file or directory. Starting program: /lib64/ld-linux-x86-64.so.2 /usr/bin/curl [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. fputc (c=99, fp=0x0) at fputc.c:37 37 fputc.c: No such file or directory. -- see shy jo signature.asc Description: Digital signature
Bug#796899: interesting segfault
Package: openssh-server Version: 1:6.9p1-1 Severity: normal /lib64/ld-linux-x86-64.so.2 /usr/bin/ssh Segmentation fault This is puzzling, AFAICS it should be the same as running ssh directly. Happens on amd64, not on i386, and didn't used to happen before probably version 1:6.9p1-1. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii dpkg 1.18.1 ii init-system-helpers1.23 ii libc6 2.19-19 ii libcomerr2 1.42.13-1 ii libgssapi-krb5-2 1.13.2+dfsg-2 ii libkrb5-3 1.13.2+dfsg-2 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2+b1 ii libssl1.0.01.0.2d-1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13+nmu1 ii openssh-client 1:6.9p1-1 ii openssh-sftp-server1:6.9p1-1 ii procps 2:3.3.10-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20150516-2 ii xauth 1:1.0.9-1 Versions of packages openssh-server suggests: pn molly-guard none pn monkeysphere none pn rssh none ii ssh-askpass 1:1.2.4.1-9 pn ufw none -- debconf information excluded -- see shy jo signature.asc Description: Digital signature
Bug#796899: Acknowledgement (interesting segfault)
reassign 796899 libc6 found 796899 2.19-19 thanks This also happens with curl, not just ssh, so reassigning to libc6. /lib64/ld-linux-x86-64.so.2 /usr/bin/curl Segmentation fault Since curl 7.44.0-1 works when run via ld.so, and curl 7.43.0-1 segfaults, I think this might have to do with the ongoing gcc transition. -- see shy jo
Bug#796948: verbose output documentation does not match actual output
Package: kpartx Version: 0.5.0-7 Severity: normal Man page: kpartx -av disk.img This will output lines such as: loop3p1 : 0 20964762 /dev/loop3 63 Reality: root@darkstar:/home/joeykpartx -avs disk add map loop0p1 (254:0): 0 192512 linear /dev/loop0 2048 It would be helpful if the man page documents that the actual output looks like, at least to the point of documenting that it starts with add map. It may be that the output format has changed since the man page was written. That's worrying. I'm not sure if the verbose output is really intended to be parsed, but there are programs that do parse it (for example, vmdebootstrap). -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kpartx depends on: ii dmsetup 2:1.02.103-1 ii libc6 2.19-19 ii libdevmapper1.02.1 2:1.02.103-1 ii udev223-2 kpartx recommends no packages. kpartx suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#795644: git-annex: configure eats all memory
Joachim Breitner wrote: I think I got it: Cabal tries to infer what feature are supported by looking at the dependencies, and their flags, and mumble mumble complex search space. Except while Cabal falls over, cabal-install does not. For example: joey@kite:~/git-annexdpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: libghc-dbus-dev (= 0.10.7) libghc-fdo-notify-dev (= 0.3) libghc-yesod-dev (= 1.2.6.1) libghc-network-protocol-xmpp-dev (= 0.4.3-1+b1) joey@kite:~/git-annexcabal configure /dev/null || echo failed joey@kite:~/git-annex (Used around 8 mb of memory) joey@kite:~/git-annex./Setup configure /dev/null || echo failed Killed failed (Used over 2 gb of memory) Note that libghc-cabal-dev was installed, so that Setup should have been built using version 1.22.1.1-2+b3. So, why does Cabal's dependency resolver perform so much worse than cabal-install's? Note that git-annex 5.20150812 went back to using cabal configure, rather than Setup configure, so I expect it will probably build everywhere again. There seems to be a bug somewhere in the cabal system however. -- see shy jo signature.asc Description: Digital signature
Bug#795644: git-annex: configure eats all memory
Joey Hess wrote: apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev libghc-http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev libghc-resourcet-dev libghc-monad-control-dev libghc-edit-distance-dev libghc-sandi-dev libghc-json-dev libghc-utf8-string-dev libghc-hslogger-dev libghc-monad-logger-dev libghc-http-conduit-dev libghc-safesemaphore-dev libghc-uuid-dev libghc-quickcheck2-dev libghc-optparse-applicative-dev libghc-cabal-dev git cabal-install Also, if you remove one of these necessary dependencies, eg libghc-optparse-applicative-dev, cabal configure -v3 will show the problem resolver exhaustively trying to resolve the dependencies and failing, without using much memory. It then goes ahead and runs Setup configure, which OOMS. -- see shy jo signature.asc Description: Digital signature
Bug#795644: git-annex: configure eats all memory
Joachim Breitner wrote: If we can isolate the problem nicely, I’ll be happy to discuss this with upstream. deboostrap sid in chroot: mount -t proc proc /proc apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev libghc-http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev libghc-resourcet-dev libghc-monad-control-dev libghc-edit-distance-dev libghc-sandi-dev libghc-json-dev libghc-utf8-string-dev libghc-hslogger-dev libghc-monad-logger-dev libghc-http-conduit-dev libghc-safesemaphore-dev libghc-uuid-dev libghc-quickcheck2-dev libghc-optparse-applicative-dev libghc-cabal-dev git cabal-install git clone git://git-annex.branchable.com/ git-annex cd git-annex ghc --make Setup cabal configure # succeeds ./Setup configure # OOM -- see shy jo signature.asc Description: Digital signature
Bug#795231: fails on cubietruck with FAT /boot
Ian Campbell wrote: The cubietruck u-boot is more than capable of booting from an ext filesystem, so you should just do that, in fact everything should work in this mode out of the box, how did you end up with a FAT /boot? Haven't upgraded from default uboot yet, which does't even support ext2.. On platforms where u-boot is only capable of reading FAT the recommended approach is to use a dedicated FAT partition which is not normally mounted and use flash-kernel's Boot-Device option to cause the boot images to be copied to it. Ok, that's reasonable.. -- see shy jo signature.asc Description: Digital signature
Bug#795231: fails on cubietruck with FAT /boot
Package: flash-kernel Version: 3.36 Severity: normal A few places in flash-kernel try to ln -s, and this fails if /boot is a FAT filesystem. It should be possible to fall back to cp in this case. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Bug#792485: etckeeper/git sets SSH host key perms to 644
Antoine Beaupré wrote: First, a big warning: By checking /etc into version control, you are creating a copy of files like /etc/shadow that must remain secret. Anytime you have a copy of a secret file, it becomes more likely that the file contents won't remain secret. etckeeper is careful about file permissions, and will make sure that repositories it sets up don't allow anyone but root to read their contents. However, you *also* must take care when cloning or copying these repositories, not to allow anyone else to see the data. That seems pretty clear to me... So I am downgrading this to a normal issue and removing the security tag as the security implications of running etckeeper are clearly stated from the start. Also, the next paragraph points out that permissions won't be restored when checking out the repository until etkeeper is run, and further on there are examples of doing checkouts in a mode 700 parent directory to avoid leaking information. Smudge filters are an interesting idea, but the current smudge interface does not provide a way to set file permissions. -- see shy jo signature.asc Description: Digital signature
Bug#793061: clone git-annex fails with OOM on server
Package: dgit Version: 1.0 Severity: normal joey@darkstar:~/tmpdgit clone git-annex canonical suite name for unstable is sid fetching existing git history remote: fatal: Out of memory, calloc failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header dgit: failed command: git fetch -p -n -q 'https://git.dgit.debian.org/git-annex' '+refs/dgit/*:refs/remotes/dgit/dgit/*' '+refs/tags/*:refs/dgit-fetch/sid/tags/*' '+refs/heads/*:refs/dgit-fetch/sid/heads/*' dgit: subprocess failed with error exit status 128 Cloning other repos, such as dgit's, works. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dgit depends on: ii ca-certificates20150426 ii coreutils 8.23-4 ii curl 7.43.0-1 ii devscripts 2.15.5 ii dpkg-dev 1.18.1 ii dput 0.9.6.4 ii git [git-core] 1:2.1.4-2.1 ii libdpkg-perl 1.18.1 ii libjson-perl 2.90-1 ii libwww-perl6.13-1 ii perl [libdigest-sha-perl] 5.20.2-6 ii realpath 8.23-4 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.7p1-6 Versions of packages dgit suggests: pn sbuild none -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#792777: fails to send email on failure; falls over on circle at start of systemctl status
Package: systemd-cron Version: 1.5.2-1 Severity: normal Jul 18 08:41:26 darkstar systemd[1]: Starting [Cron] @reboot mpd... Jul 18 08:41:26 darkstar sh[1906]: Jul 18 08:41 : socket: Failed to bind to '[::]:6600': Address already in use Jul 18 08:41:26 darkstar systemd[1]: cron-joey-joey-1.service: Main process exited, code=exited, status=1/FAILURE Jul 18 08:41:26 darkstar systemd[1]: Failed to start [Cron] @reboot mpd. Jul 18 08:41:26 darkstar systemd[1]: cron-joey-joey-1.service: Unit entered failed state. Jul 18 08:41:26 darkstar systemd[1]: cron-joey-joey-1.service: Triggering OnFailure= dependencies. Jul 18 08:41:26 darkstar systemd[1]: cron-joey-joey-1.service: Failed with result 'exit-code'. Jul 18 08:41:26 darkstar systemd[1]: Created slice system-cron\x2dfailure.slice. Jul 18 08:41:26 darkstar systemd[1]: Starting system-cron\x2dfailure.slice. Jul 18 08:41:26 darkstar systemd[1]: Starting systemd-cron OnFailure for cron-joey-joey-1... Jul 18 08:41:26 darkstar mail_on_failure[1909]: Traceback (most recent call last): Jul 18 08:41:26 darkstar mail_on_failure[1909]: File /lib/systemd-cron/mail_on_failure, line 43, in module Jul 18 08:41:26 darkstar mail_on_failure[1909]: systemctl = subprocess.check_output(['systemctl','status',job], universal_newlines=True) Jul 18 08:41:26 darkstar mail_on_failure[1909]: File /usr/lib/python3.4/subprocess.py, line 609, in check_output Jul 18 08:41:26 darkstar mail_on_failure[1909]: output, unused_err = process.communicate(inputdata, timeout=timeout) Jul 18 08:41:26 darkstar mail_on_failure[1909]: File /usr/lib/python3.4/subprocess.py, line 949, in communicate Jul 18 08:41:26 darkstar mail_on_failure[1909]: stdout = _eintr_retry_call(self.stdout.read) Jul 18 08:41:26 darkstar mail_on_failure[1909]: File /usr/lib/python3.4/subprocess.py, line 491, in _eintr_retry_call Jul 18 08:41:26 darkstar mail_on_failure[1909]: return func(*args) Jul 18 08:41:26 darkstar mail_on_failure[1909]: File /usr/lib/python3.4/encodings/ascii.py, line 26, in decode Jul 18 08:41:26 darkstar mail_on_failure[1909]: return codecs.ascii_decode(input, self.errors)[0] Jul 18 08:41:26 darkstar mail_on_failure[1909]: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal not in range(128) Jul 18 08:41:26 darkstar systemd[1]: cron-failure@cron-joey-joey-1.service: Main process exited, code=exited, status=1/FAILURE Jul 18 08:41:26 darkstar systemd[1]: Failed to start systemd-cron OnFailure for cron-joey-joey-1. Jul 18 08:41:26 darkstar systemd[1]: cron-failure@cron-joey-joey-1.service: Unit entered failed state. Jul 18 08:41:26 darkstar systemd[1]: cron-failure@cron-joey-joey-1.service: Failed with result 'exit-code'. This seems to be trying to mail the output of systemctl status. joey@darkstar:~systemctl status cron-joey-joey-1.service|hexdump -C e2 97 8f 20 63 72 6f 6e 2d 6a 6f 65 79 2d 6a 6f |... cron-joey-jo| 0010 65 79 2d 31 2e 73 65 72 76 69 63 65 20 2d 20 5b |ey-1.service - [| 0020 43 72 6f 6e 5d 20 22 40 72 65 62 6f 6f 74 20 6d |Cron] @reboot m| 0030 70 64 22 0a 20 20 20 4c 6f 61 64 65 64 3a 20 6c |pd. Loaded: l| So, the 0xe2 it falls over on is the very first character, the circle ● cron-joey-joey-1.service - [Cron] @reboot mpd -- Package-specific info: -- output of systemd-delta -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-cron depends on: ii init-system-helpers 1.23 ii python3 3.4.3-4 ii systemd-sysv 222-1 Versions of packages systemd-cron recommends: ii postfix [mail-transport-agent] 2.11.3-1 systemd-cron suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#791379: [pkg-gnupg-maint] Bug#791379: gpg2 fails to use agent started by Xsession; automatically started agent works ok
Daniel Kahn Gillmor wrote: On Fri 2015-07-03 23:31:57 -0400, Joey Hess wrote: Package: gnupg-agent Version: 2.1.0-1 Severity: normal I'm a little surprised by this version of gnupg-agent -- i don't think it's available anywhere in debian for quite some time. Hmm, I think I must have installed gnupg2 from experimental back when this version was originally released. Unstable is still back on version 2.0 so it's not upgraded yet. My guess is that you're using pinentry-gnome3 and preferring it over pinentry-gtk2 -- there is a bugfix for gnupg-agent in unstable at the moment (2.0.28-3) to pass through DBUS_SESSION_BUS_ADDRESS, and it is already present in 2.1.6, which should be uploaded to experimental sometime today or tomorrow. The problem certianly has something to do with pinentry-gnome3. -- see shy jo signature.asc Description: Digital signature
Bug#791379: gpg2 fails to use agent started by Xsession; automatically started agent works ok
Marco d'Itri wrote: Are you using pinentry-gnome3 or pinentry-gtk-2? The first one is probably broken right now for you too. The problem indeed seems to be rooted in pinentry-gnome3. I switched the alternative to pinentry-gtk2 (which I prefer anyway) and it has no problem working. -- see shy jo signature.asc Description: Digital signature
Bug#791378: [Pkg-xfce-devel] Bug#791378: conflicts with /etc/X11/Xsession.d/90gpg-agent and unsets GPG_AGENT_INFO
Yves-Alexis Perez wrote: Well, this variable is not set by default, and the code explicitly checks for TRUE so you seem to had it set to TRUE somewhere. The settings editor did not display the variable until I manually added it, so I don't see how it could have been set before. -- see shy jo signature.asc Description: Digital signature
Bug#791354: download progress display loses info with high concurrentcy
Package: apt Version: 1.0.9.10 Severity: normal apt does an excellent job of displaying download progress, packing a lot of info into a single line in a very smart way. But, with httpredir.debian.org in use (or perhaps due to some other change) apt seems to do a lot of concurrent downloads. It now seems typical, during a large upgrade, for the overall progress to not be visible, pushed so far off the right side that even a fullscreen terminal can't display it: 72% [206 linux-image-4.0.0-2-amd64 23.1 MB/34.7 MB 67%] [272 libghc-tagstream-conduit-dev 158 kB/220 kB 72%] [270 xfce4-weather-plugin 758 kB/2,446 kB Think it might be better to move the time estimate and whatever else is in the overall progress to the left hand side, where the overall percent already is, so it's always visible even with so many concurrent downloads. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-4\.0\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-4\.0\.0-1-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4;
Bug#791378: conflicts with /etc/X11/Xsession.d/90gpg-agent and unsets GPG_AGENT_INFO
Package: xfce4-session Version: 4.12.1-3 Severity: normal At some point after the jessie release, an upgrade broke the gpg agent; while the agent started on login, GPG_AGENT_INFO was not set. gpg2 could the agent, but gpg v1 was unable to do so. I added debugging to /etc/X11/Xsession.d/90gpg-agent and could see that it was setting GPG_AGENT_INFO: + /usr/bin/gpg-agent + GPG_AGENT_INFO=/home/joey/.gnupg/S.gpg-agent:0:1 + export GPG_AGENT_INFO But, later along, xfce4-session did something that unset that variable: + exec /usr/bin/dbus-launch --exit-with-session x-session-manager /usr/bin/x-session-manager: X server already running on display :0 gpg-agent: a gpg-agent is already running - not starting a new one (xfce4-session:10715): xfce4-session-WARNING **: gpg-agent returned no PID in the variables I noticed there's a /startup/gpg-agent/enabled to control whether xfce4-session does this, and after manually adding that setting in the xfce configuration editor, and setting it to false, the problem went away on next login. So, xfce4-session is clearly stomping on the toes of /etc/X11/Xsession.d/90gpg-agent. Without reading its source code, but just looking at strings, I hypothesize it's running gpg-agent, expecting some output that it no longer produces, and then clobbering the already correctly set GPG_AGENT_INFO. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-session depends on: ii libatk1.0-02.16.0-2 ii libc6 2.19-18 ii libcairo2 1.14.2-2 ii libdbus-1-31.8.18-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-4 ii libgdk-pixbuf2.0-0 2.31.4-2 ii libglib2.0-0 2.44.1-1.1 ii libgtk2.0-02.24.28-1 ii libice62:1.0.9-1+b1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpolkit-gobject-1-0 0.105-8 ii libsm6 2:1.2.2-1+b1 ii libwnck22 2.30.7-2 ii libx11-6 2:1.6.3-1 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util7 4.12.1-2 ii libxfconf-0-2 4.12.0-2+b1 ii multiarch-support 2.19-18 ii xfce4-settings 4.12.0-2 ii xfconf 4.12.0-2+b1 Versions of packages xfce4-session recommends: ii dbus-x11 1.8.18-1 ii libpam-systemd 221-1 ii systemd-sysv 221-1 ii upower 0.99.3-1+b1 ii x11-xserver-utils 7.7+4 ii xfdesktop4 4.12.2-1 ii xfwm4 4.12.3-1 pn xscreensaver none Versions of packages xfce4-session suggests: pn fortunes-mod none pn pm-utils none ii sudo 1.8.12-1 -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#791379: gpg2 fails to use agent started by Xsession; automatically started agent works ok
Package: gnupg-agent Version: 2.1.0-1 Severity: normal Every time I log in, gpg2 fails to access my secret key; something is preventing it from using the gpg agent to prompt for the passphrase: joey@darkstar:~ps -fax |grep gpg-agent 15743 ?Ss 0:00 /usr/bin/gpg-agent --daemon 15967 pts/2S+ 0:00 \_ grep gpg-agent joey@darkstar:~gpg2 --decrypt me.gpg gpg: encrypted with 4096-bit RSA key, ID 17065459, created 2009-06-17 Joey Hess i...@joeyh.name gpg: public key decryption failed: Operation cancelled gpg: decryption failed: No secret key If I kill the gpg-agent process started by Xsession, and let gpg2 start the agent up for itself, it works: joey@darkstar:~kill 15743 joey@darkstar:~ps -fax |grep gpg-agent 16008 pts/2S+ 0:00 \_ grep gpg-agent joey@darkstar:~gpg2 --decrypt me.gpg gpg: encrypted with 4096-bit RSA key, ID 17065459, created 2009-06-17 Joey Hess i...@joeyh.name hi This is a new problem seen after an upgrade today, and it happens every time. (gpg v1 is able to use the gpg-agent started by Xsession without difficulty) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnupg-agent depends on: ii libassuan0 2.2.1-1 ii libc6 2.19-18 ii libgcrypt20 1.6.3-2 ii libgpg-error0 1.19-2 ii libnpth01.2-1 ii libreadline66.3-8+b3 ii pinentry-gnome3 [pinentry] 0.9.4-2 ii pinentry-gtk2 [pinentry]0.9.4-2 Versions of packages gnupg-agent recommends: ii gnupg 1.4.19-3 ii gnupg2 2.1.0-1 ii gpgsm 2.1.0-1 gnupg-agent suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#785736: git-annex documentation should be made reproducible.
Simon McVittie wrote:
By the way, I notice Joey has marked this bug as pending by adding
$config{deterministic} and TZ. You might also want LC_ALL=C.UTF-8
to make sure nothing gets translated - $config{deterministic} doesn't
set TZ or LC_ALL. (Unless you think it should?)
I think not. I'll set LC_ALL.
--
see shy jo
signature.asc
Description: Digital signature
Bug#788269: machinectl loses track of running systemd-nspawn machines
Package: systemd Version: 220-5 Severity: normal For some reason, after a period of hours or days, systemd-nspawn containers that are still running are no longer listed by machinectl. root@elephant:~systemctl status systemd-nspawn@oldusenet-shellbox.service ● systemd-nspawn@oldusenet-shellbox.service - Container oldusenet/shellbox Loaded: loaded (/etc/systemd/system/multi-user.target.wants/systemd-nspawn@oldusenet-shellbox.service) Active: active (running) since Fri 2015-06-05 11:17:02 JEST; 4 days ago Docs: man:systemd-nspawn(1) Main PID: 25613 (systemd-nspawn) Status: Container running. CGroup: /machine.slice/systemd-nspawn@oldusenet-shellbox.service ├─25613 /usr/bin/systemd-nspawn --quiet --keep-unit --boot --direc... ├─25660 /lib/systemd/systemd └─system.slice ├─dbus.service │ └─25739 /usr/bin/dbus-daemon --system --address=systemd: --nof... ├─cron.service │ └─25731 /usr/sbin/cron -f ├─oldusenet.service ... root@elephant:~machinectl MACHINE CLASS SERVICE 0 machines listed. root@elephant:~journalctl --since '2015-06-05' | grep systemd-machined Jun 05 11:17:02 elephant systemd-machined[25661]: New machine oldusenet-shellbox. Jun 08 03:40:19 elephant systemd-machined[25661]: Machine oldusenet-shellbox terminated. So, machinectl thinks it terminated, but the service is actually still running. If I stop and restart this service, machinectl will list it for a while, and then again lose it. Observed this repeatedly on 2 boxes, both running 220-5. A third box with 215-18 and otherwise similar configuration does not have the problem. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787174: more proof
-- see shy jo
Bug#787935: seems to use a dead API
Package: libbusiness-paypal-api-perl Version: 0.70-1 Severity: normal Since a week ago, the paypal api service this module uses has been failing with 503 or 500. My guess is this means paypal has killed that API, presumably replacing it with a new API. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Bug#786727: crashes with segfault when drawLineH is called
John Millikin wrote: I've not been able to reproduce this on my workstation, which is running Jessie. Installed package versions: ghc: [7.6.3, 7.8.4, 7.10.1] c2hs: [0.17.2] haskell-ncurses: [0.2.7, 0.2.11] libncursesw5-dev: [5.9+20140913-1+b1] That stack trace posted in the OP is suspicious. It looks like drawBorder is being called somehow, but there is no path for the posted code snippet to reach drawBorder. This makes me believe the stack is getting corrupted. The only change between 0.2.7 and 0.2.11 that seems related is 08137f194f66796a68bf38886d3944caf7b9d08e, which added support for c2hs=0.18.2 by adding ifdefs for some new pointer semantics. I believe this change is semantically a no-op, but there might be something going on in the FFI code that I'm not aware of. What version of c2hs are you using? I'll try building with that to see if it triggers the issue for me. c2hs is 0.25.2 I'll bet that if you debootstrap a chroot of debian unstable, you'll be able to reproduce it in there. Adding to the stack-smashing hypothesis, I got this backtrace just now: #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33 #1 0x00415ede in ckTj_info () #2 0x in ?? () -- see shy jo signature.asc Description: Digital signature
Bug#787174: closed by Joey Hess i...@joeyh.name (Re: Bug#787174: remove unblockable new tab ads)
https://bugzilla.mozilla.org/show_bug.cgi?id=1103599 So I'm not the only one to have filed a bug about this, which was closed with no, that can't be! Also, perhaps relevant that I have DNT enabled in preferences. Some of mozilla's own documentation claims that these ads are not shown when DNT is enabled. Perhaps they got the logic totally backwards. -- see shy jo signature.asc Description: Digital signature
Bug#787480: build with iptables support
Package: systemd Version: 220-3 Severity: normal File: systemd-networkd I'm trying to use systemd-networkd with systemd-nspawn --private-network --port now that a systemd supporting this feature has convenently landed in unstable early. ;) Jun 01 20:14:03 clam systemd-networkd[4629]: ve-t3: Could not enable IP masquerading: Operation not supported Seems that networkd needs to be linked to libiptc.so for that to work. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.26.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod220-1 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.26.2-6 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 220-3 ii mount 2.26.2-6 ii sysv-rc 2.88dsf-59.2 ii udev220-3 ii util-linux 2.26.2-6 Versions of packages systemd recommends: ii dbus1.8.18-1 ii libpam-systemd 220-3 Versions of packages systemd suggests: pn systemd-ui none -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#787480: build with iptables support
Michael Biebl wrote: We were reluctant to link against libiptc, since that would mean a dependency on iptables, which is about 4M of additional disk space which even minimal systems would have to install. Given the recent upstream discussions [1] to switch to nftables, we will probably wait a bit, until things have settled, before turning this feature on. Hope that makes sense. Isn't libnftnl0 bigger than iptables anyway? -- see shy jo signature.asc Description: Digital signature
Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or direc
Helmut Grohne wrote: Are you sure that /proc is mounted in that chroot? Maybe this is a duplicate of #773768? Totally is a dup of that, thanks! In light of the possible exploitability of this misconfiguration as a security hole, it seems that ghc should be fixed to not look for libraries in relative paths in this case, as well as printing a more useful error message.. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or direc
Joachim Breitner wrote: Hi, Am Samstag, den 30.05.2015, 10:00 -0400 schrieb Joey Hess: Helmut Grohne wrote: Are you sure that /proc is mounted in that chroot? Maybe this is a duplicate of #773768? Totally is a dup of that, thanks! In light of the possible exploitability of this misconfiguration as a security hole, it seems that ghc should be fixed to not look for libraries in relative paths in this case, as well as printing a more useful error message.. I don’t think ghc even has the chance to do something else here, this is the linker failing, isn’t it? Sorry, I meant the linker should be fixed, not ghc. -- see shy jo signature.asc Description: Digital signature
Bug#787174: remove unblockable new tab ads
Package: iceweasel Version: 38.0.1-5 Severity: normal The new tab page has been infested with ads provided by Mozilla. For example, I have seen ads for FedEx, and for some web password service. The only way to turn them off is to disable viewing tiles at all in the new tab page. Please disable this adware antifeature in iceweasel. -- see shy jo signature.asc Description: Digital signature
Bug#787227: broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or direc
Package: ghc Version: 7.8.4-8 Severity: important root@honeybee:/# ghc /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No such file or directory root@honeybee:/# ls -l /usr/lib/ghc/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.4.so -rw-r--r-- 1 root root 2105712 May 25 20:47 /usr/lib/ghc/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.4.so The problem isn't unique to this one .so file: root@honeybee:/# hsc2hs /usr/lib/ghc/bin/hsc2hs: error while loading shared libraries: libHSprocess-1.2.0.0-ghc7.8.4.so: cannot open shared object file: No such file or directory root@honeybee:/# ldd /usr/lib/ghc/bin/hsc2hs | grep libHSprocess libHSprocess-1.2.0.0-ghc7.8.4.so = /usr/lib/ghc/bin/../process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so (0xb6d9d000) root@honeybee:/# ls -l /usr/lib/ghc/process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so -rw-r--r-- 1 root root 156452 May 25 20:47 /usr/lib/ghc/process-1.2.0.0/libHSprocess-1.2.0.0-ghc7.8.4.so (Strange that ldd is able to resolve the paths to the libraries when ld-linux.so cannot..) LD_DEBUG=all hsc2hs sheds some light on the problem. Comparing with the output on amd64 and armhf, it seems that the linker is seeing a RUNPATH that has tls/v7l/neon/vfp in it, instead of a RUNPATH that gives the directories where the haskell libraries are. So, maybe something in the armel toolchain is overwriting the RUNPATH? Horrible workaround: Make a ./tls/v7l/neon/vfp/ directory, and copy all the libraries from ghc into it. :/ root@honeybee:/tmp# cp $(dpkg -L ghc |grep \.so) ./tls/v7l/neon/vfp/ root@honeybee:/tmp# ghc -V The Glorious Glasgow Haskell Compilation System, version 7.8.4 armhf LD_DEBUG=all excerpt: 4088: search path=/usr/lib/ghc/bin/../process-1.2.0.0:/usr/lib/ghc/bin/../directory-1.2.1.0:/usr/lib/ghc/bin/../unix-2.7.0.1:/usr/lib/ghc/bin/../time-1.4.2:/usr/lib/ghc/bin/../old-locale-1.0.0.6:/usr/lib/ghc/bin/../filepath-1.3.0.2:/usr/lib/ghc/bin/../containers-0.5.5.1:/usr/lib/ghc/bin/../bytestring-0.10.4.0:/usr/lib/ghc/bin/../deepseq-1.3.0.2:/usr/lib/ghc/bin/../array-0.5.0.0:/usr/lib/ghc/bin/../base-4.7.0.2:/usr/lib/ghc/bin/../integer-gmp-0.5.1.0:/usr/lib/ghc/bin/../ghc-prim-0.3.1.0:/usr/lib/ghc/bin/../rts-1.0 (RUNPATH from file /usr/lib/ghc/bin/hsc2hs) armel LF_DEBUG=all complete output for resolving the libHSprocess lib: 3791: file=libHSprocess-1.2.0.0-ghc7.8.4.so [0]; needed by /usr/lib/ghc/bin/hsc2hs [0] 3791: find library=libHSprocess-1.2.0.0-ghc7.8.4.so [0]; searching 3791: search path=tls/v7l/neon/vfp:tls/v7l/neon:tls/v7l/vfp:tls/v7l:tls/neon/vfp:tls/neon:tls/vfp:tls:v7l/neon/vfp:v7l/neon:v7l/vfp:v7l:neon/vfp:neon:vfp: (RUNPATH from file /usr/lib/ghc/bin/hsc2hs) 3791: trying file=tls/v7l/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/v7l/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=tls/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=v7l/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=neon/vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=neon/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=vfp/libHSprocess-1.2.0.0-ghc7.8.4.so 3791: trying file=libHSprocess-1.2.0.0-ghc7.8.4.so 3791: search cache=/etc/ld.so.cache 3791: search
Bug#787227: Acknowledgement (broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No s
Note that this bug is likely a security hole; /usr/bin/ghc loading .so files relative to the CWD could be exploted. When ghc's postinst runs ghc-pkg, it seems that dpkg does something that prevents those relative paths being used (possibly just a chdir, didn't check). So, it's at least not trivially exploitable by getting root to install ghc when root is in /tmp. -- see shy jo signature.asc Description: Digital signature
Bug#787227: Acknowledgement (broken on armel due to broken RUNPATH: /usr/lib/ghc/bin/ghc: error while loading shared libraries: libHShaskeline-0.7.1.2-ghc7.8.4.so: cannot open shared object file: No s
FWIW, I have seen this on 2 machins: * Bannana pi, running bannanian with a Debian armel chroot * Cubietruck, running an image from https://romanrm.net/a10/debian with a Debian armel chroot In both cases, the kernel and boot system are armhf. I don't know if this nonstandard configuration has something to do with it. -- see shy jo signature.asc Description: Digital signature
Bug#787174: remove unblockable new tab ads
Mike Hommey wrote: - search for devtools.chrome.enabled and toggle it. - search for devtools.debugger.remote-enabled and toggle it. Thanks for that useful tip! - Press F10, open the Tools menu Web Developer Browser toolbox - Select the Network pane - open a new tab Here, in Classic mode, no request happens. In Enhanced mode, a request is done to tiles.services.mozilla.com. Same here. However, I definitely have never had Enhanced mode enabled (except while testing this). And, both times I saw ads in Classic mode, they appeared first thing in the morning, when the computer had just been resumed from sleep. So I hypothesize there is some kind of scheduling there[1], and it won't request every time. (Also, the tiles.services.mozilla.com request is not done every time a tab opens in enhanced mode; there's scheduling/caching there too.) -- see shy jo [1] Morning seems a good time to launch a mindworm attack. Defenses are down before coffee. signature.asc Description: Digital signature
Bug#786659: Do not depend on libghc-hamlet-dev
Actually I have had to revert fixing this until I can update the git-annex autobuilders to include the new version of shakespeare. Which, will take quite a lot of work unforunately, and is currently blocked by Debian testing's haskell packages having all kinds of broken dependencies right now. -- see shy jo signature.asc Description: Digital signature
Bug#786727: Acknowledgement (crashes with segfault when drawLineH is called)
I get the same crash with ghc 7.6.3, and libncurses5 5.9+20140913-1+b1 with ncurses-0.2.11. On the same system, ncurses-0.2.7 works ok. So, this seems to point to the new version of (haskell) ncurses being where the problem lies. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786724: seems to forget about containers that were running when it was upgraded
Package: docker.io Version: 1.6.2~dfsg1-1 Severity: normal root@elephant:/usr/local/propellor#joeyconfigdocker start kiteshellbox.elephant.kitenet.net.propellor Error response from daemon: Cannot start container kiteshellbox.elephant.kitenet.net.propellor: [8] System error: Unit docker-8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a.scope already exists. FATA[] Error: failed to start one or more containers root@elephant:/usr/local/propellor#joeyconfigsystemctl status docker-8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a.scope ● docker-8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a.scope - docker container 8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a Loaded: loaded Drop-In: /run/systemd/system/docker-8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a.scope.d └─50-BlockIOAccounting.conf, 50-CPUAccounting.conf, 50-Description.conf, 50-MemoryAccounting.conf, 50-Slice.conf Active: active (running) since Thu 2015-03-12 20:08:22 JEST; 2 months 12 days ago CGroup: /system.slice/docker-8b0ea86c864c612cc843ee17689956add6d6877a3dadf7040069bd4a3b0a8c1a.scope ├─ 5916 /usr/local/propellor/docker/kiteshellbox.elephant.kitenet.net.propellor.shim/lib64/propellor --library-path /usr/local/propellor/... ├─11560 /usr/bin/shellinaboxd -q --background=/var/run/shellinaboxd.pid -c /var/lib/shellinabox -p 443 -u shellinabox -g shellinabox --us... ├─11561 /usr/bin/shellinaboxd -q --background=/var/run/shellinaboxd.pid -c /var/lib/shellinabox -p 443 -u shellinabox -g shellinabox --us... ├─19890 bash -l ├─19892 bash -l └─19895 id -u docker ps doesn't show this container, which was set up before docker was upgraded to this new release. But, the container is actually running. here's what docker ps --all shows: 8b0ea86c864cjoeyh/debian-stable-amd64:latest \/usr/local/propel 10 weeks agoExited (-1) 2 days ago kiteshellbox.elephant.kitenet.net.propellor At this point I don't know how to clean up. I tried systemctl stop to stop the procecesses, which it did, but docker start still fails the same way. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages docker.io depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.23 ii iptables 1.4.21-2+b1 ii libapparmor1 2.9.2-3 ii libc62.19-18 ii libdevmapper1.02.1 2:1.02.90-2.2 ii libsqlite3-0 3.8.10.2-1 ii perl 5.20.2-6 Versions of packages docker.io recommends: ii aufs-tools 1:3.2+20130722-1.1 ii ca-certificates 20141019 ii cgroupfs-mount 1.2 ii git 1:2.1.4-2.1 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages docker.io suggests: pn btrfs-tools none ii debootstrap 1.0.70 pn lxc none pn rinsenone -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#786659: Do not depend on libghc-hamlet-dev
Joachim Breitner wrote: please do not depend on libghc-hamlet-dev, it has been superceded by libghc-shakespeare-dev. hamlet ist scheduled for removal (#783682). I noticed that and it was fixed in the 5.20150522 release. I am still waiting for algernon or someone to start uploading releases to Debian. -- see shy jo signature.asc Description: Digital signature
Bug#786724: Acknowledgement (seems to forget about containers that were running when it was upgraded)
Occurs to me that I might have had docker running in a screen session to get debug messages for the intermittent bug where docker dies of a signal. I forget if I did, but that might have prevented a clean shutdown on the upgrade? I rebooted the host, and /var/lib/docker still had a lot of images in it, but docker didh't know about anything. And starting new images failed with some error message I didn't note down. I had to purge docker, rm -rf /var/lib/docker and reinstall to get back to a usable state. -- see shy jo signature.asc Description: Digital signature
Bug#786727: crashes with segfault when drawLineH is called
Package: libghc-ncurses-dev Version: 0.2.11-1+b1 Severity: normal This program crashes with a segfault. import UI.NCurses main = runCurses $ do w - defaultWindow updateWindow w $ do drawLineH (Just (Glyph ' ' [])) 80 This didn't used to happen; the library was working when I wrote scroll earlier this spring. Something, perrhaps the new version of C ncurses, or the upgrade from ncurses-0.2.7 to 0.2.11, or the update from ghc 7.6.3 to 7.8.4, must have broken it. FWIW, I get the same crash if I install ncurses with cabal. (gdb) bt #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33 #1 0x00415ede in ncurseszm0zi2zi11_UIziNCurses_drawBorder3_info () #2 0x in ?? () -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libghc-ncurses-dev depends on: ii ghc [libghc-transformers-dev-0.3.0.0-6458c] 7.8.4-6 ii libc62.19-18 pn libghc-base-dev-4.7.0.2-bfd89none pn libghc-containers-dev-0.5.5.1-d4bd8 none ii libghc-text-dev [libghc-text-dev-1.1.1.3-1cb5a] 1.1.1.3-2+b2 ii libncurses5-dev 5.9+20150516-2 ii libncursesw5 5.9+20150516-2 ii libncursesw5-dev 5.9+20150516-2 ii libtinfo55.9+20150516-2 libghc-ncurses-dev recommends no packages. Versions of packages libghc-ncurses-dev suggests: ii libghc-ncurses-doc 0.2.11-1 pn libghc-ncurses-prof none -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#785736: git-annex documentation should be made reproducible.
Daniel Kahn Gillmor wrote: And ikiwiki defaults to sorting the inlined pages by age, if i'm reading IkiWiki/Plugin/inline.pm correctly. I suppose the source documentation is unpacked from the tarball with non-deterministic timestamps, which makes sorting by age non-deterministic. sort=age uses the ctime of the page. Which will vary between unpacks of the source I guess. If the source were a git repository, ikiwiki would get the actual ctime from git, which would be stable. Pity Debian doesn't use git repositories as source.. git-annex has a lot of inlines in its documentation, so I don't much like changing them all to sort=mtime; it's asking for later bugs. Also, sorting by mtime is not necessarily what I want on the website. I think this is a case where ikiwiki should have changes to support deterministic builds. If enabled, it could force sorting everything by mtime rather than ctime. Or it could even use the mtime as the ctime in that mode. Or, Debian source package unpacking could set the ctime to the mtime.. -- see shy jo signature.asc Description: Digital signature
Bug#785736: git-annex documentation should be made reproducible.
Daniel Kahn Gillmor wrote: Hi, this is an attempt to clear up at least one source of unreproducibility in git-annex. https://reproducible.debian.net/rb-pkg/unstable/amd64/git-annex.html shows that the documentation shipped with git-annex appears to embed the timestamp of the build. The embedded timestamp should probably be set based on the timestamp in the most recent changelog entry. mdash;·span·class=dateSat·Oct·19·06:05:52·2013/span mdash;·span·class=dateSun·Oct·20·08:05:52·2013/span Unless you built in 2013, and cooincidentally at the same MM:SS each time, that's not the timestamp of the build. I suspect this is a stable timestamp (taken from the file timestamp) with rendering varying by locale. If so, git-annex's Makefile could avoid this by setting LANG=C when it runs ikiwiki. diff --git a/Makefile b/Makefile index 14e55a4..350145b 100644 --- a/Makefile +++ b/Makefile @@ -73,7 +73,7 @@ man: mkdir -p man docs: mans - $(IKIWIKI) doc html -v --wikiname git-annex --plugin=goodstuff \ + LANG=C $(IKIWIKI) doc html -v --wikiname git-annex --plugin=goodstuff \ --no-usedirs --disable-plugin=openid --plugin=sidebar \ --underlaydir=/dev/null --disable-plugin=shortcut \ --disable-plugin=smiley \ If this can be confirmed to fix it in your test apparatus, I'll make the change.. -- see shy jo signature.asc Description: Digital signature
Bug#785738: ikiwiki comment produces non-deterministic URLs
[ Please CC me, I am not subscribed to the debian BTS as I don't maintain ikiwiki in Debian any longer, and have not tried to manually subscribe yet. ] So, I think we need to think about performance here. In the cgiurl() case, performance of sorting a small hash of url parameters is almost certianly not going to matter. But, if there turn out to be lots of other places in ikiwiki that expose hash order, which is at least possible, sorting all of them may be a performance issue. Then it would probably make sense to have a way to enable determanistic builds if desired, but not by default. -- see shy jo signature.asc Description: Digital signature
Bug#784777: unable to get filename suffix for youtube
Package: quvi Version: 0.4.2-2 Severity: normal Something has changed in youtube, and quvi often no longer reports any file_suffix for youtube videos, while still being able to provide the url to the media file. This may break some tools that use quvi and didn't realize that might be omitted. (git-annex was one, now fixed) I have not checked if quvi 0.9 has this problem. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages quvi depends on: ii dpkg 1.17.24 ii libc62.19-17 ii libcurl3-gnutls 7.38.0-4 ii libquvi7 0.4.1-3 quvi recommends no packages. quvi suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#777577: new upstream version available
At this point I'm wondering myself what the holdup is on getting an upload of git-annex into Debian. There are probably several hundred bug fixes, and dozens of new features. -- see shy jo signature.asc Description: Digital signature
Bug#784348: wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink
Package: wget Version: 1.16-3 Severity: normal joey@darkstar:~/tmp/yln -s /etc/passwd README joey@darkstar:~/tmp/yls README@ joey@darkstar:~/tmp/ywget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README --2015-05-05 13:17:22-- ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README = ‘foo’ Resolving ftp.funet.fi (ftp.funet.fi)... 193.166.3.2, 2001:708:10:9::20:2 Connecting to ftp.funet.fi (ftp.funet.fi)|193.166.3.2|:21... connected. Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD (1) /pub/Linux/mirrors/debian ... done. == SIZE README ... 1495 == PASV ... done.== RETR README ... done. Length: 1495 (1.5K) (unauthoritative) README 100%[=] 1.46K 5.45KB/s in 0.3s 2015-05-05 13:17:28 (5.45 KB/s) - ‘foo’ saved [1495] joey@darkstar:~/tmp/yls foo Doesn't happen if README is a file rather than a symlink, doesn't happen when using http. The ftp downloader apparently has a bug.. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wget depends on: ii libc6 2.19-17 ii libgnutls-deb0-28 3.3.8-6 ii libidn11 1.29-1+b2 ii libnettle4 2.7.1-5 ii libpsl00.5.1-1 ii libuuid1 2.25.2-5 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages wget recommends: ii ca-certificates 20141019 wget suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#782533: #769951 still exists
Package: mpd Version: 0.19.1-1.1 Severity: normal I just experienced a bug identical to #769951 while running the version of mpd that claims to have fixed it. I followed the documentation in /etc/default/mpd and disabed it by running sudo update-rc.d mpd disable After reboot, init was listening on :6600 until I ran: sudo systemctl disable mpd.socket This was on a system freshly installed from stable and upgraded to unstable today. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mpd depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii libadplug-2.2.1-0 2.2.1+dfsg3-0.1 ii libao41.1.0-3 ii libasound21.0.28-1 ii libaudiofile1 0.3.6-2+b1 ii libavahi-client3 0.6.31-4+b2 ii libavahi-common3 0.6.31-4+b2 ii libavcodec56 6:11.3-1 ii libavformat56 6:11.3-1 ii libavutil54 6:11.3-1 ii libbz2-1.01.0.6-7+b2 ii libc6 2.19-17 ii libcdio-cdda1 0.83-4.2 ii libcdio-paranoia1 0.83-4.2 ii libcdio13 0.83-4.2 ii libcurl3-gnutls 7.38.0-4 ii libdbus-1-3 1.8.16-1 ii libexpat1 2.1.0-6+b3 ii libfaad2 2.7-8 ii libflac8 1.3.0-3 ii libfluidsynth11.1.6-2 ii libglib2.0-0 2.42.1-1 ii libgme0 0.5.5-2 ii libicu52 52.1-8 ii libid3tag00.15.1b-11 ii libiso9660-8 0.83-4.2 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libmad0 0.15.1b-8 ii libmikmod33.3.7-1 ii libmms0 0.6.2-4 ii libmodplug1 1:0.8.8.4-4.1+b1 ii libmp3lame0 3.99.5+repack1-7 ii libmpcdec62:0.1~r459-4.1 ii libmpdclient2 2.9-1 ii libmpg123-0 1.20.1-2 ii libnfs4 1.9.5-2 ii libogg0 1.3.2-1 ii libopenal11:1.15.1-5 ii libopus0 1.1-2 ii libpulse0 5.0-13 ii libresid-builder0c2a 2.1.1-14 ii libroar2 1.0~beta11-1 ii libsamplerate00.1.8-8 ii libshout3 2.3.1-3 ii libsidplay2 2.1.1-14 ii libsidutils0 2.1.1-14 ii libsmbclient 2:4.1.17+dfsg-2 ii libsndfile1 1.0.25-9.1 ii libsoxr0 0.1.1-1 ii libsqlite3-0 3.8.7.4-1 ii libstdc++64.9.2-10 ii libsystemd0 215-12 ii libupnp6 1:1.6.19+git20141001-1 ii libvorbis0a 1.3.4-2 ii libvorbisenc2 1.3.4-2 ii libvorbisfile31.3.4-2 ii libwavpack1 4.70.0-1 ii libwildmidi1 0.3.7-1 ii libwrap0 7.6.q-25 ii libyajl2 2.1.0-2 ii libzzip-0-13 0.13.62-3 ii lsb-base 4.1+Debian13+nmu1 ii zlib1g1:1.2.8.dfsg-2+b1 mpd recommends no packages. Versions of packages mpd suggests: ii avahi-daemon 0.6.31-4+b2 pn icecast2 none ii mpc [mpd-client] 0.26-1 ii ncmpc [mpd-client] 0.24-1 pn pulseaudio none ii sonata [mpd-client] 1.6.2.1-6 -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#778987: closed by Sven Bartscher sven.bartsc...@weltraumschlangen.de (Bug#778987: fixed in haskell-cabal-install 1.20.0.3-3)
Seems a pity this is only being fixed in experimental. If Debian releases with a cabal that does not even work in the default configuration, I suspect this will increase the Haskell community's general tendency to not use Debian's haskell infrastructure. -- see shy jo signature.asc Description: Digital signature
Bug#781352: ssl cert fail causes pumpa to exit, deleting in-progress post
Package: pumpa Version: 0.9-1 Severity: normal If I have a note I'm trying to post, and the current wifi network is a typical horrible gatewayed public wifi network, the post may fail a couple of times. I'll then go do something else. In the meantime, pumpa will try to refresh the timeline. Then pumpa will complain that it got a bad ssl cert. Then it will exit. This causes the words I was trying to post to get lost. I suggest pumpa not exit in this situation, but instead just fail whatever network operation is being blocked by the MITM. (Not filing at grave bug severity because meh, it's just words. How important can words be? ...) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pumpa depends on: ii libaspell15 0.60.7~20110707-3 ii libc6 2.19-17 ii libgcc1 1:4.9.2-10 ii libqjson0 0.8.1-3 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3 ii libstdc++6 4.9.2-10 ii libtidy-0.99-0 20091223cvs-1.4 pumpa recommends no packages. pumpa suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#779455: broken versioned dependencies
Package: perl-modules Version: 5.20.2-1 Severity: normal Depends: perl-base (= 5.20.1-3) But, this version of perl-modules installs modules in /usr/share/perl/5.20.2, while that version of perl-base contains /usr/share/perl/5.20 - 5.20.1 I noticed this when perl -e 'use UNIVERSAL' started failing.. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages perl-modules depends on: ii dpkg 1.17.23 ii perl 5.20.1-5 ii perl-base 5.20.1-5 Versions of packages perl-modules recommends: ii libarchive-extract-perl0.72-1 ii libcgi-pm-perl 4.09-2 ii libmodule-build-perl 0.421000-2 ii libmodule-pluggable-perl 5.1-1 ii libpackage-constants-perl 0.04-1 ii libpod-latex-perl 0.61-1 ii libterm-ui-perl0.42-1 ii libtext-soundex-perl 3.4-1+b2 Versions of packages perl-modules suggests: pn libb-lint-perl none pn libcpanplus-dist-build-perl none pn libcpanplus-perl none pn libfile-checktree-perl none ii liblog-message-perl 0.8-1 ii liblog-message-simple-perl 0.10-2 pn libobject-accessor-perl none -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#779455: Acknowledgement (broken versioned dependencies)
Can't locate UNIVERSAL.pm in @INC (you may need to install the UNIVERSAL module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.1 /usr/local/share/perl/5.20.1 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/perl5/IPC/Run.pm line 1059. BEGIN failed--compilation aborted at /usr/share/perl5/IPC/Run.pm line 1059. Compilation failed in require at /usr/bin/chronic line 37. BEGIN failed--compilation aborted at /usr/bin/chronic line 37. -- see shy jo signature.asc Description: Digital signature
Bug#778987: mismatched versions of cabal-install and Cabal result in build failures
Package: cabal-install Version: 1.20.0.3-1 Severity: normal Since Cabal is back at version 1.16.0, a package with a custom Setup.hs will be built linked against that. However, cabal-install 1.20 puts things in the default ~/.cabal/config that cause such a Setup to crash. For example: joey@darkstar:~/src/git-annexcabal configure Config file path source is default config file. Config file /home/joey/.cabal/config not found. Writing default configuration to /home/joey/.cabal/config Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal update' to download it. Resolving dependencies... unrecognized option `--extra-prog-path=/home/joey/.cabal/bin' -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cabal-install depends on: ii libc6 2.19-13 ii libffi6 3.1-2+b2 ii libgmp10 2:6.0.0+dfsg-6 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages cabal-install recommends: ii ghc 7.6.3-20 cabal-install suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#778800: -0 NaN
Package: xfce4-weather-plugin Version: 0.8.3-2 Severity: minor See attached screenshot of -0 F, which is not really a number. (The actual temp at the time was -0.4 F, so rounding bug.) -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-weather-plugin depends on: ii libatk1.0-0 2.14.0-1 ii libc62.19-13 ii libcairo21.14.0-2.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libsoup2.4-1 2.48.0-1 ii libxfce4ui-1-0 4.10.0-6 ii libxfce4util64.10.1-2 ii libxml2 2.9.2+dfsg1-2 ii xfce4-panel 4.10.1-1 xfce4-weather-plugin recommends no packages. xfce4-weather-plugin suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#778714: use system libsqlite instead of embedded code copy
Source: haskell-persistent-sqlite Version: 1.3.0.5-1+b1 Severity: normal There is an embedded copy of sqlite in this library. It's currently rather old, and even the latest persistent-sqlite from hackage embeds an out of date version. sqlite sometims has bugs. It may even have security bugs. Avoiding using this embedded code copy would avoid stumbling over old bugs as I did today, and avoid security update pain. There's a systemlib build flag in the cabal file, so this should be easy to do. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Bug#777577: new upstream version available
Antoine Beaupré wrote: It seems that new releases of git-annex do not trickle down into Debian anymore. This package isn't orphaned yet, Joey: are you still planning on publishing updates to it in Debian? Gergely Nagy is maintaining it in Debian. It would be nice to get an upload with his name on it, and possibly a new version in exprimental. -- see shy jo signature.asc Description: Digital signature
Bug#777234: RFP: haskell-docs -- find and display haddock docs at console
Package: wnpp Severity: wishlist * Package name: haskell-docs * URL : http://hackage.haskell.org/package/haskell-docs * License : BSD3 Programming Lang: haskell Description : haskell program to find and display haddock docs This would be a useful addition to the haskell development tools in Debian. It works with -doc packages. -- see shy jo signature.asc Description: Digital signature
Bug#774898: has anyone actually tested this patch?
Holger Levsen wrote: has anyone actually tested this patch? Yes. -- see shy jo signature.asc Description: Digital signature
Bug#776424: can be crashed by some network traffic
Source: kgb-bot Version: 1.33-2 Severity: important Tags: security 2015.01.19 18:08:39: Listening on http://0.0.0.0:?session=KGB 2015.01.19 18:08:43: Connected to freenode (holmes.freenode.net) 2015.01.19 18:08:43: Joining #commits... 2015.01.19 18:08:43: Connected to oftc (graviton.oftc.net) 2015.01.19 18:08:43: Joining #ikiwiki #vcs-home #git-annex... Did not get DONE/CLOSE event for Wheel ID 73 from IP 222.186.34.155 at /usr/share/perl5/POE/Component/Server/SimpleHTTP.pm line 221. I had a problem posting to event Got_Request of session SOAPServer for DIR handler '.*'. As reported by Kernel: 'No such file or directory', perhaps the session name is spelled incorrectly for this handler? at /usr/share/perl5/POE/Session.pm line 483. This has happened to me twice now, and it takes the bot down. root@elephant:/home/joeysystemctl status kgb-bot.service ● kgb-bot.service - LSB: Collaborative IRC helper Loaded: loaded (/etc/init.d/kgb-bot) Active: active (exited) since Mon 2015-01-19 14:08:39 JEST; 1 weeks 1 days ago Process: 26584 ExecReload=/etc/init.d/kgb-bot reload (code=exited, status=0/SUCCESS) Jan 26 03:57:27 elephant kgb-bot[26584]: Reloading Collaborative IRC helper: kgb-bot. systemd thinks the service is running ok, but the daemon has in fact crashed or exited because of the event logged above. Both service kbg-bot start and systemctl start kgb-bot do nothing. I have to service kgb-bot stop to get out of this state. (It seems that this could stand to be improved, by eg, writing a systemd service file that doesn't let the daemon fork, so systemd can handle logging and know when the process has exited.) Here's the log from the previous time it happened: 2015.01.15 23:05:33: Connected to freenode (wolfe.freenode.net) 2015.01.15 23:05:33: Joining #commits... Did not get DONE/CLOSE event for Wheel ID 1089 from IP 222.186.34.155 at /usr/share/perl5/POE/Component/Server/SimpleHTTP.pm line 221. I had a problem posting to event Got_Request of session SOAPServer for DIR handler '.*'. As reported by Kernel: 'No such file or directory', perhaps the session name is spelled incorrectly for this handler? at /usr/share/perl5/POE/Session.pm line 483. I don't know the IP 222.186.34.155. I assume it is trying to exploit my server with its DIR .* Since this appears to be at least a DOS, I've tagged the bug as a minor security issue. -- see shy jo signature.asc Description: Digital signature
Bug#775373: apparenty fails deb-rpm with filenames containing [ or ]
Package: alien Severity: normal Going through and cleaning out my todo folder for alien, I found an email from an alien user who reported the following bug. I have not tried to verify the problem, but it seems likely that alien is exposing filenames to the shell. --- I have a problem: I'm having problems with deb-rpm convertion when included files have filenames with [ or ] (example ultrastar-deluxe-songs_20100506-2_all.deb ) (I'm not sure this is the reason of the error) sudo alien --to-rpm ultrastar-deluxe-songs_20100506-2_all.deb ... lots of errors like: File not found by glob: /home/jj/Download/ultrastar-deluxe-songs-20100506/usr/share/ultrastardx/songs/Bodo Wartke - Liebeslied/Bodo Wartke - Liebeslied [CO].jpg - -- see shy jo signature.asc Description: Digital signature
Bug#774987: xfce cd lacks gnome-keyring, so network-manager cannot connect to many networks
Package: debian-cd Severity: normal gnome-keyring is a recommend of network-manager-gnome. While network-manager-gnome is included on the xfce CD, gnome-keyring is not. It should be. I noticed this when installing stable, but testing appears to also have the problem. An install from the xfce CD w/o network will result in an installed system that lacks gnome-keyring. When attempting to connect to a wifi network that needs a password, network-manager will immediately fail, and display a very non-useful the network connection has been disconnected alert. Many users at this point will be stuck and not able to figure out why their system is broken. Adding gnome-keyring as a depend to tasks that include network-manager-gnome would be one way to solve this, if fixing the debian-cd recommends resolution code is intractable. It would probably be a good idea to compare installs from CD with and w/o network, and see what recommended packages get left off. There are likely other land-mines like this one lurking. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Bug#774986: /lib/firmware/b43 has strange permissions
Package: firmware-b43-installer Version: 1:019-1 Severity: minor drwxr-x--- 2 root root 4096 Jan 9 13:30 /lib/firmware/b43/ -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firmware-b43-installer depends on: ii b43-fwcutter 1:019-1 ii bzip2 1.0.6-7+b2 ii wget 1.16-3 firmware-b43-installer recommends no packages. firmware-b43-installer suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#768516: Up for grabs
Antoine Beaupré wrote: Actually, joeyh: how should we do this? Should I fork the git repo in to collab-maint? Otherwise I'd be happy to push debian-related changes to the upstream git repo: git://etckeeper.branchable.com/ ... if that's what you prefer. Yes, I can give ssh keys commit access there. I'm ccing Remi, who contacted me about maintaining etckeeper more recently. -- see shy jo signature.asc Description: Digital signature
Bug#774898: fails to detect silent driver failure to change MAC
Package: macchanger
Version: 1.7.0-5
Severity: normal
Tags: security
(Note that I have obscured my actal MAC with XX in this bug report.)
root@darkstar:~macchanger wlan0 -m aa:bb:cc:dd:ee:ff
Current MAC: 40:f0:2f:XX:XX:XX (Liteon Technology Corporation)
Permanent MAC: 40:f0:2f:XX:XX:XX (Liteon Technology Corporation)
New MAC: aa:bb:cc:dd:ee:ff (unknown)
root@darkstar:~ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 40:f0:2f:XX:XX:XX
It seems that the r8723au kernel driver for my wifi device silently
ignores attempts to change the MAC.
macchanger tries to detect if the new MAC is the same as the old.
However, it does this by calling mc_net_info_get_mac, on the same
net_info structure that it's called mc_net_info_set_mac on.
So, mc_net_info_set_mac sets the mac *in the data structure*, then calls
SIOCSIFHWADDR, which returns success without doing anything because the
kernel driver is buggy. And then mc_net_info_get_mac examines the data
structure, without calling SIOCGIFHWADDR to check if the MAC was
actually changed.
I suggest the attached patch to actively verify if the MAC was changed.
I'm tagging this security, because silently failing to change the MAC,
while claiming it was changed, may lead the user into trouble, if they
were changing their MAC for security reasons.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages macchanger depends on:
ii debconf [debconf-2.0] 1.5.55
ii dpkg 1.17.23
ii install-info 5.2.0.dfsg.1-6
ii libc6 2.19-13
macchanger recommends no packages.
macchanger suggests no packages.
-- debconf information excluded
--
see shy jo
diff --git a/src/main.c b/src/main.c
index 182082e..d57ce4d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -264,10 +264,6 @@ main (int argc, char *argv[])
/* Set the new MAC */
ret = mc_net_info_set_mac (net, mac_faked);
if (ret == 0) {
- /* Re-read the MAC */
- mc_mac_free (mac_faked);
- mac_faked = mc_net_info_get_mac(net);
-
/* Print it */
print_mac (New MAC: , mac_faked);
@@ -276,6 +272,18 @@ main (int argc, char *argv[])
printf (It's the same MAC!!\n);
exit (EXIT_ERROR);
}
+
+ /* Re-read the MAC in case a driver silently ignores
+* attempt to set it */
+ mc_net_info_free (net);
+ if ((net = mc_net_info_new(device_name)) == NULL) {
+ exit (EXIT_ERROR);
+ }
+ mac = mc_net_info_get_mac(net);
+ if (! mc_mac_equal (mac, mac_faked)) {
+ printf (Network driver didn't actually change to the
new MAC!!\n);
+ exit (EXIT_ERROR);
+ }
}
/* Memory free */
signature.asc
Description: Digital signature
Bug#774441: blogspam plugin needs updating for API change
Simon McVittie wrote: This should be fixed in experimental now. For unstable and jessie, could someone who actively uses blogspam (I don't) please test the attached diff relative to 3.20141016? I've been running the updated blogspam on Branchable (debian stable) for 4 days with no complaints. -- see shy jo signature.asc Description: Digital signature
Bug#774494: git-annex: migrate hash to hashE still re-checksums
A Mennucc wrote: I read in changelog: « Avoid re-checksumming when migrating from hashE to hash backend.» I am migrating a repository from SHA256 to SHA256E should be faster in newer versions. You are migrating in the other direction and the optimisation doesn't apply there. -- see shy jo signature.asc Description: Digital signature
Bug#774441: blogspam plugin needs updating for API change
Package: ikiwiki Version: 3.20141017 Severity: important https://ikiwiki.info/bugs/blogspam_server_stopped_supporting_xml-rpc I feel that a total lack of ability to block spam is something worth fixing in wheezy, and probably backporting to stable. -- see shy jo signature.asc Description: Digital signature
Bug#774376: when run with old kernel, docker exec silently uses real root filesystem as container filesystem
Package: docker.io Version: 1.3.3~dfsg1-1 Severity: serious Here's a system that was upgraded to unstable but not yet rebooted into the new kernel.. root@clam:~uname -a Linux clam 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux root@clam:~touch /hello-host root@clam:~docker exec oldusenet-shellbox.clam.kitenet.net.propellor ls /hello-host /hello-host This is pretty horrible! Note that only docker exec behaves this way; docker run and docker attach operate with the filesystem correctly chrooted to the container. Also, it seems that not only the filesystem, but process namespacing is broken. root@clam:~docker exec oldusenet-shellbox.clam.kitenet.net.propellor ps -ax |grep grep 20600 pts/4S+ 0:00 grep grep I didn't check network namespacing, but my guess is docker fails to enter any namespace because of the old kernel, and then fails to propigate the error because Fail. There does not seem to be anything interesting in docker.log. I have filed this severity serious as a compromise. I think this bug could cause data loss. Using docker exec to do part of a container's deployment, and deploying changes to the host system could result in arbitrary horrible effects, up to and including removing files from the host system. However, in my case, I luckily was deploying a new system, so I can throw away the resulting mess. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages docker.io depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 ii iptables 1.4.21-2+b1 ii libapparmor1 2.9.0-3 ii libc62.19-13 ii libdevmapper1.02.1 2:1.02.90-2 ii libsqlite3-0 3.8.7.4-1 ii perl 5.20.1-4 Versions of packages docker.io recommends: ii aufs-tools 1:3.2+20130722-1.1 ii ca-certificates 20141019 ii cgroupfs-mount 1.1 ii git 1:2.1.4-2 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages docker.io suggests: pn btrfs-tools none ii debootstrap 1.0.66 pn lxc none pn rinsenone -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#774376: when run with old kernel, docker exec silently uses real root filesystem as container filesystem
Tianon Gravi wrote: I would actually be very surprised if the issues you've encountered so far are the only issues with Docker on a 3.2 kernel. Just to be clear, my intent was not to use docker with an old kernel. I was just deploying a system whose configuration included docker, and since docker started up despite the old kernel version, it was used as part of the deployment. This could happen lots of other ways too, like the wrong kernel being chosen in a boot menu. I agree that docker should refuse to run if used with an old kernel. This could be done in the Debian init script if not upstream. -- see shy jo signature.asc Description: Digital signature
Bug#774315: RFP: haskell-disk-free-space -- Retrieve information about disk space usage.
Package: wnpp Severity: wishlist * Package name: haskell-disk-free-space * URL : http://hackage.haskell.org/package/disk-free-space * License : BSD3 git-annex currently contains its own implementation of a portable disk free space and size checking library. In a future version, I'd like to drop this code, and instead use the new disk-free-space from hackage. It will work on at least Linux, OSX, and Windows. Probably on the BSDs, but I have not checked. So, it would be nice to get this into Debian before-hand. -- see shy jo signature.asc Description: Digital signature
Bug#774247: sleepd: Option to prevent sleep on open TCP connections
justus.pia...@uibk.ac.at wrote: I'd like to see this patch (or an improved version) applied upstream (whatever this means, as it is dead and buried according to http://joeyh.name/code/). Or else, please let me know about an alive-and-well alternative to sleepd. It seems to me that systemd and logind is the modern replacement for sleepd. They can, for example, be configured to not let the system sleep while logind has an open login session, incuding one from ssh. I am no longer maintaining sleepd upstream (or in Debian). If someone wants to take over maintenance, that would be fine. -- see shy jo signature.asc Description: Digital signature
Bug#774001: ${#@} and ${#*} are incompatable with bash and posh
Package: dash
Version: 0.5.7-4+b1
Severity: normal
joey@darkstar:~cat testcase
#!/bin/sh
echo ${#@}
joey@darkstar:~bash testcase a
1
joey@darkstar:~posh testcase a
1
joey@darkstar:~dash testcase a
1
good so far...
joey@darkstar:~bash testcase a b
2
joey@darkstar:~posh testcase a b
2
joey@darkstar:~dash testcase a b
3
!!
joey@darkstar:~bash testcase a b c
3
joey@darkstar:~posh testcase a b c
3
joey@darkstar:~dash testcase a b c
5
joey@darkstar:~bash testcase aaa bbb
3
joey@darkstar:~posh testcase aaa bbb
3
joey@darkstar:~dash testcase aaa bbb
12
posh:
${#name}
The number of positional parameters if name is *, @ or is
not specified, or the length of the string value of
parameter name.
bash:
${#name[subscript]} expands to the length of ${name[sub‐
script]}. If subscript is * or @, the expansion is the number
of elements in the array.
dash:
${#parameter} String Length. The length in characters
of the value of parameter.
So dash's documentation doesn't specify what it does for ${#@}. What its
actually doing is taking the length of the string consisting of all the
positional parameters, separated by spaces.
I have not checked if the behavior of ${#@} is standardized in any way.
If ${#@} is standardized, then dash should follow the standard.
Currently, a #!/bin/sh script cannot currently safely use ${#@}, because
/bin/sh can be dash or bash. If some package contains a #!/bin/dash
script, it could rely on the current behavior. OTOH, the behavior is
undocumented, and seems pretty useless, so it's unlikely someone would
go to the bother of using #!/bin/dash to get it. This might argue for
changing the behavior to match bash and posh even if there is not a
standard.
On the other hand, $# reliably yields the number of positional parameters
in all of bash, posh, and dash. So any script can use that. So, the easiest
fix would be to just document on its man page the special way bash handles
${#@} (and ${#*})
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dash depends on:
ii debianutils 4.4+b1
ii dpkg 1.17.22
ii libc62.19-13
dash recommends no packages.
dash suggests no packages.
-- debconf information excluded
--
see shy jo
signature.asc
Description: Digital signature
Bug#774004: man page typo
Package: posh Version: 0.12.3 Severity: minor ++ similar to ++, except the parameter is decremented by 1. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages posh depends on: ii debconf [debconf-2.0] 1.5.55 ii libc6 2.19-13 posh recommends no packages. posh suggests no packages. -- debconf information excluded -- see shy jo signature.asc Description: Digital signature
Bug#773821: getPathVar fails to use statfs64() on i386 and can overflow
Package: ghc
Version: 7.6.3-20
Severity: normal
import System.Posix.Files
import Control.Exception
import Foreign.C.Types
main = print = (try (getPathVar . FileNameLimit) :: IO (Either IOException
CLong))
This program can fail on a system with a large disk:
Left .: getPathVar: failed (Value too large for defined data type)
statfs(., 0xffa8ad50) = -1 EOVERFLOW (Value too large for
defined data type)
The problem is, getPathVar is using statfs, not statfs64.
Here's a C program that uses statfs64:
#define _LARGEFILE64_SOURCE 1
#include sys/vfs.h
#include stdio.h
main () {
struct statfs64 buf;
statfs64(., buf);
printf(%li\n, buf.f_namelen);
}
And strace shows just how large some of the fields are, which is why
statfs() overflows.
statfs64(., 84, {f_type=0x2fc12fc1, f_bsize=131072, f_blocks=67107265,
f_bfree=66904371, f_bavail=66904371, f_files=17127878964, f_ffree=17127519173,
f_fsid={-676822403, 15770009}, f_namelen=255, f_frsize=131072, f_flags=4128}) = 0
An added problem is that getPathVar is implemented using pathconf,
rather than using statfs directly. It seems that setting _LARGEFILE64_SOURCE
does not cause pathconf to use statfs64. This may be a glibc bug.
--
see shy jo
signature.asc
Description: Digital signature
Bug#753986: nondeterministic
Use first vcs from $LIST *is* nondeterministic. It means that people who happen to have bzr installed from ancient days of yore when anything used bzr will get a etckeeper using bzr if they apt-get install etckeeper. And then on a second system that didn't have that cruft installed, they'll get an etckeeper using git. I have no interest in supporting that clusterfuck, and frankly the prospect makes me itch to remove all !git support from etckeeper. It's bad enough that distributions like ubuntu have overrideen the default in the past. So, wontfix. -- see shy jo signature.asc Description: Digital signature
Bug#773619: page load fail makes it difficult to cook cornbread in the woodstove
Package: iceweasel
Version: 31.3.0esr-1
Severity: normal
Recipe:
1. Go to remote cabin heated by woodstove, with dialup internet access.
Wait until the morning fire is burnt down to coals. That would be a
perfect rustic way to bake some cornbread in a dutch oven.
2. Start loading page http://www.tasteofhome.com/recipes/corn-bread
3. After text has loaded, but before all images and other assets are
loaded, over the next 10 minutes or so, start following
instructions to make cornbread.
4. Get knocked offline by phone call.
5. While taking last look at recipe, the displayed page is suddenly
replaced with this error message:
Unable to connect
Iceweasel can't establish a connection to the server at
www.tasteofhome.com.
I hope this shows how this behavior can be very frustrating. FWIW,
chromium never behaves this way; a failure to load part of the page or
an asset just results in a partially loaded page being displayed.
-- Package-specific info:
-- Extensions information
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: Certificate Patrol
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/certpat...@psyc.eu
Package: xul-ext-certificatepatrol
Status: user-disabled
Name: Default theme
Location:
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled
Name: DuckDuckGo Plus
Location: ${PROFILE_EXTENSIONS}/jid1-zadieub7xoz...@jetpack.xpi
Status: enabled
Name: Element Hiding Helper for Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/elemhidehel...@adblockplus.org
Package: xul-ext-adblock-plus-element-hiding-helper
Status: user-disabled
Name: Firebug
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: enabled
Name: Grab and Drag
Location: ${PROFILE_EXTENSIONS}/{477c4c36-24eb-11da-94d4-00e08161165f}.xpi
Status: enabled
Name: Monkeysphere
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/tls-xul-...@monkeysphere.info
Package: xul-ext-monkeysphere
Status: enabled
Name: Perspectives
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/perspecti...@cmu.edu
Package: xul-ext-perspectives
Status: user-disabled
Name: Privacy Badger Firefox
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled
-- Plugins information
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: disabled
Name: Shockwave Flash (11.2.202.406)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled
-- Addons package information
ii iceweasel 31.3.0esr-1 amd64Web browser based on Firefox
ii rhythmbox-plug 3.1-1amd64plugins for rhythmbox music playe
ii xul-ext-adbloc 2.6.6+dfsg-1 all advertisement blocking extension
ii xul-ext-adbloc 1.3-1all companion for Adblock Plus to cre
ii xul-ext-certif 2.0.14-4 all Certificate Monitor for Iceweasel
ii xul-ext-firebu 2.0.4-1 all web development plugin for Icewea
ii xul-ext-monkey 0.8-1all Iceweasel/Firefox extension for u
ii xul-ext-perspe 4.5.2-1 all verify HTTPS sites through notary
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages iceweasel depends on:
ii debianutils 4.4+b1
ii fontconfig2.11.0-6.3
ii libasound21.0.28-1
ii libatk1.0-0 2.14.0-1
ii libc6 2.19-13
ii libcairo2 1.14.0-2.1
ii libdbus-1-3 1.8.12-1
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-52.0.21-stable-1.1
ii libffi6 3.1-2+b2
ii libfontconfig12.11.0-6.3
ii libfreetype6 2.5.2-2
ii libgcc1 1:4.9.2-8
ii libgdk-pixbuf2.0-02.31.1-2+b1
ii libglib2.0-0 2.42.1-1
ii libgtk2.0-0 2.24.25-1
ii libhunspell-1.3-0 1.3.3-3
ii libnspr4 2:4.10.7-1
ii libnss3 2:3.17.2-1
ii libpango-1.0-01.36.8-3
ii libsqlite3-0 3.8.7.2-1
ii libstartup-notification0 0.12-4
ii libstdc++64.9.2-8
ii libvpx1 1.3.0-3
ii libx11-6 2:1.6.2-3
ii libxext6 2:1.3.3-1
ii libxrender1
Bug#773619: Acknowledgement (page load fail makes it difficult to cook cornbread in the woodstove)
(PS the cornbread turned out great) -- see shy jo signature.asc Description: Digital signature
Bug#773551: RFP: haskell-torrent -- haskell torrent parsing
Package: wnpp Severity: wishlist http://hackage.haskell.org/package/torrent License: BSD3 Upcoming versions of git-annex will use this library to parse torrent files. While it can fall back to building without the library, and instead use the btshowmetainfo utility, that's not a recommended configuration (that utility is not really designed to have machine parsable output AFAICS). So it would be good to get this library (and its dependency bencode) into Debian. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772911: fails to run program +[,.]
Package: hsbrainfuck
Version: 0.1-6
Severity: normal
joey@darkstar:~echo +[,.] | hsbrainfuck
Killed
Strace shows the program sitting in some kind of tight loop,
including:
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
8096) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
+++ killed by SIGKILL +++
I'm unclear why it gets a SIGKILL; it does not seem to run out of memory.
The brainfuck program was generated using brainfuck-monad,
with this haskell code.
cat = brainfuckConstants 1 $ flip forever $ input output
AFAICs that should just print to stdout what's read from stdin.
The program works when run in beef(1).
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages hsbrainfuck depends on:
ii libc6 2.19-13
ii libffi6 3.1-2
ii libgmp10 2:6.0.0+dfsg-6
hsbrainfuck recommends no packages.
hsbrainfuck suggests no packages.
-- no debconf information
--
see shy jo
signature.asc
Description: Digital signature
Bug#772427: sulogin segfaults if shadow passwords are not enabled
Package: sysvinit-utils Version: 2.88dsf-58 Severity: normal I deployed a system accidentially without shadow passwords enabled (all user accounts had * in /etc/passwd), and sulogin failed with sulogin: cannot open password database! It then segfaulted. Which is the bug. Interestingly, systemd continued with the boot and the system came up otherwise ok. Note that this is perhaps a more common configuration than might be expected. For example, when using systemd-nspawn on a debootstrapped chroot, the container that is booted up is in exactly this configuration. If for some reason the boot proceess of that container needs to call sulogin, it will presumably fail the same way. -- see shy jo signature.asc Description: Digital signature
Bug#772199: opens files RDWR
Package: mp3rename
Version: 0.6-9
Severity: normal
Tags: patch
For some reason mp3rename opens files RDWR. I don't see why it does
this, as it is not going to change the content of a file.
open(www.archive.org_download_gd70_01_02.early_late.sbd.cotsman.18120.sbeok.shnf_gd70_01_02d1t01_vbr.mp3,
O_RDWR) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1633024, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fde14544000
read(3, ID3\3\0\0\0\0\0xTIT2\0\0\0\31\0\0\0Zarathustra..., 4096) = 4096
fstat(3, {st_mode=S_IFREG|0644, st_size=1633024, ...}) = 0
lseek(3, 1630208, SEEK_SET) = 1630208
read(3,
3\243\31(\342\3210X=\332\10\341\16(Y\250\247\0t\372\320stW\276=\377\10\33n\251Y...,
4096) = 2816
fstat(3, {st_mode=S_IFREG|0644, st_size=1633024, ...}) = 0
lseek(3, 1633024, SEEK_SET) = 1633024
fstat(3, {st_mode=S_IFREG|0644, st_size=1633024, ...}) = 0
lseek(3, 1633024, SEEK_SET) = 1633024
close(3)= 0
munmap(0x7fde14544000, 4096)= 0
rename(www.archive.org_download_gd70_01_02.early_late.sbd.cotsman.18120.sbeok.shnf_gd70_01_02d1t01_vbr.mp3,
(Grateful Dead)-Zarathustra introduction.mp3) = 0
This is particularly annoying when using git-annex, or I suppose
anything else that removes the write bit from files.
Ok, seems that -f and -a modify the file to add a new tag.
So, I suggest this patch:
diff -ur x/mp3rename-0.6/mp3rename.c mp3rename-0.6/mp3rename.c
--- x/mp3rename-0.6/mp3rename.c 2014-12-05 22:02:10.0 -0400
+++ mp3rename-0.6/mp3rename.c 2014-12-05 21:59:19.509943882 -0400
@@ -99,7 +99,12 @@
char title[31]=, artist[31]=, album[31]=, year[5]=, comment[31]=,
fbuf[4],
newfilename[160]=,nieuw[150]=,dir[150]=,dirsource[200],fullline[228]=,
burnname[29]=, track;
plaatsen = 0;
- if ( !( fp=fopen(*argv,rb+) ) )/* If the file doesn exist */
+ char mode[4];
+ if ((forced) || (all))
+sprintf(mode, rb+);
+ else
+sprintf(mode, rb);
+ if ( !( fp=fopen(*argv,mode) ) )/* If the file doesn exist */
{
perror(Error opening file);
++argv; /* Prepare for the next file */
signature.asc
Description: Digital signature
Bug#772200: can delete precious grateful dead tuning tracks
Package: mp3rename Version: 0.6-9 Severity: normal If two mp3 files in the same directory have identical id3tags, running mp3rename on both will rename them both to the same filename. Naturally, this results in the loss of one of the files' content. (Not filing as grave to not be an asshole and because my files are backed up 6 ways to sunday and checked into git too, so this behavior was only a little puzzling and not data-loss.) I think that mp3rename should either bail out, or add something to make a unique filename in this case. -- see shy jo signature.asc Description: Digital signature
Bug#772043: option parsing 100% broken
Package: guthub-backup Version: 1.20141110 Severity: serious joey@darkstar:~/src/github-backup./github-backup joeyh Usage: github-backup [USERNAME|ORGANIZATION] [--exclude USERNAME/REPOSITORY] This leaves the program mostly useless, unable to backup all a user's repos, although it can still be run in a git repo to back up just that one single repo. The fix is simple, and I have released a new version upstream that fixes this bug. Here's the entire substantive patch: - owneropt = (argument (Just . Owner)) + owneropt = Owner $ (argument str) -- see shy jo signature.asc Description: Digital signature
Bug#771334: upgrade hosed dovecot; Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY
Source: dovecot Version: 1:2.2.13-7 Severity: serious After upgrading to this version, I cannot connect to dovecot's imap or pop servers. joey@darkstar:~telnet kitenet.net imap Trying 66.228.36.95... Connected to kite.kitenet.net. Escape character is '^]'. Connection closed by foreign host. Offlineimap fails connecting to imaps; the ssl handshake fails. journald has logged: Nov 28 11:33:44 kite dovecot[14616]: imap-login: Fatal: Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY Nov 28 11:33:44 kite dovecot[14604]: master: Error: service(imap-login): command startup failed, throttling for 4 secs Nov 28 11:33:48 kite dovecot[14616]: imap-login: Fatal: Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY Nov 28 11:33:48 kite dovecot[14604]: master: Error: service(imap-login): command startup failed, throttling for 8 secs I suppose it's not cooincidental that the change in -7 had something to do with cert locations. My dovecot cert appears to be in /etc/dovecot/private/dovecot.pem, and it starts with -BEGIN PRIVATE KEY- Downgrading to -6 worked around this. -- see shy jo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768511: ITA: dpkg-repack -- puts an unpacked .deb file back together
Guillem Jover wrote: Ok, thanks for clarifying! One last question, there seems to be some discrepancy between the license stated in debian/copyright and the license blurb in the perl script. Would you sign off on the attached patch? All code I've written in dpkg-repack is licensed under GPL-2+ -- see shy jo signature.asc Description: Digital signature
Bug#770905: assistant keeps CPU 100% busy
You were asking about the assistant's monitoring of /usr/bin/git-annex and auto-restarting on change at around this time. Do you think that could be related? How is annex.autoupgrade configured? git annex webapp causes browser to start but there it is stuck at Starting webapp... This would kind of suggest the whole process is in a bad state, if its web serving thread isn't replying. lr-x-- 1 yoh yoh 64 Nov 24 08:58 8 - /home/yoh/.config/git-annex/autostart This is unusual, because the assistant only has 2 functions that open this file; one writes a new repository to it, and one reads it at program start time and should not keep it open for long, and doesn't seem to in my tests. -- see shy jo signature.asc Description: Digital signature
Bug#771020: O: git-remote-gcrypt -- encrypted git repositories
Package: wnpp Severity: normal I am not a DD and cannot maintain this package any longer. I'm sort of upstream for it still. -- see shy jo signature.asc Description: Digital signature
Bug#771011: git-remote-gcrypt: Fails to connect to GPG agent due to --no-tty
Vagrant Cascadian wrote: Thanks for maintaining git-remote-gcrypt! Ah drat, I forgot about this package. It needs a Debian maintainer. I'm sort of kind of upstream for it but only because the actual upstream is not anwsering. When attempting to connect to a remote, I get the following... git remote update Fetching origin + [ x/run/user/1000/keyring/gpg:0:1 != x ] + gpg --no-tty --armor --gen-rand 1 9 + set +x gcrypt: Development version -- Repository format MAY CHANGE gcrypt: Decrypting manifest + [ x/run/user/1000/keyring/gpg:0:1 != x ] + gpg --no-tty --status-fd 3 -q -d gpg: anonymous recipient; trying secret key 0123456789ABCDEF ... gpg: Sorry, no terminal at all requested - can't get input gcrypt: Failed to decrypt manifest! error: Could not fetch origin I don't understand why it doesn't use GPG_AGENT_INFO ... other programs have no trouble using it. I don't think there's any particularly strange configuration on my part... If I unset GPG_AGENT_INFO it prompts me directly multiple times, but does work... if I add --use-agent it also works, so here's a patch to try that, not sure if it has other consequences: I guess I'd worry this would make it not work when there is no agent. Note that --no-tty is only supposed to be passed to gpg when there is not controlling terminal. -- see shy jo signature.asc Description: Digital signature
Bug#770658: fails to debootstrap debian on fedora: Failure trying to run: chroot /debian mount -t proc proc /proc
Package: debootstrap Version: 1.0.64 Severity: normal W: Failure trying to run: chroot /debian mount -t proc proc /proc This is because mount is in a different location in fedora than in debian. On Debian, it's in /bin/mount, while on fedora, /usr/bin/mount. And, on fedora, root's default path does not contain /bin: [root@alien /]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin So, chroot tries each of those directories, does not find mount in them in the debian chroot, and fails. Suggested fix: Before chrooting into the debootstrapped chroot to run commands, debootstrap should ensure that the PATH includes all directories it does on a standard debian system. Eg: PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin This way, the host system's chroot etc will still be found whereever it's PATH has them, and the debian system's commands will likewise be found. -- see shy jo signature.asc Description: Digital signature
Bug#770214: source tarball should not be compressed with xz
Package: debootstrap Version: 1.0.64 Severity: normal xz is not a common format, and this makes it unncessarily difficult to install debootstrap from source on unfamiliar linux systems. The space savings are miniscule. Please switch to a tar.gz. -- see shy jo signature.asc Description: Digital signature
Bug#770217: cannot be run from source on !debian
Package: debootstrap Version: 1.0.64 Severity: normal make devices.tar.gz runs MAKEDEV, so the instructions to run debootstrap from source don't work on !debian. setup_devices contains old code to bind mount /dev when it's managed by devfs. Updating that code to check for /dev managed by udev and bind mounting then might be one approach to improve this. The resulting chroot would need to have /dev/ bind mounted into it in order to be used, which seems reasonable. Alternatively, a debootstrap tarball could be provided targeting this use case, including a prebuilt devices.tar.gz. Alternatively, the devices.tar.gz Makefile target could, if MAKEDEV is not in path, just tar up the system's /dev to make it. I suspect that some people in this situation download the .deb from debian and manually unpack it to get a prebuilt devices.tar.gz. Although this requires both ar and (for no good reason) xz, which are not universally available outside debian systems. -- see shy jo signature.asc Description: Digital signature
Bug#770275: nspawn units a bit hard to get working
Package: systemd Version: 215-5+b1 Severity: normal A few problems with using systemd-nspawn@$foo.service units on Debian: * /var/lib/container doesn't exist, so the admin will have to make the directory in order to put containers where systemd expects to find them. If the admin does make the directory, they'll probably make it mode 755 or something. But this allows local users to do eg, hard link farming to gather suid executables to exploit later, that would otherwise not be available but might be lying around in some poorly maintained containers. So, I think the debian package should create the directory with an appropriate locked down mode like 700. (Which works fine.) * Once a nspawn unit is enabled and started, it will fail to run. This is because persistent journaling is not enabled by default, and the default for the service file is to use --link-journal=guest, which doesn't work w/o at least the journal directory existing (I don't know if it works when the directory exists but persistent journaling is otherwise disabled. Workaround: Edit the service file (or override the ExecStart line) to remove that switch after systemctl enable creates the file. It seems to me that --link-journal=auto would be a better value. -- see shy jo signature.asc Description: Digital signature
Bug#770145: tilde in urls
Package: pumpa Version: 0.9-1 Severity: normal I pasted this url into a note: https://vote.debian.org/~secretary/gr_initcoupling/tally.txt On cicking on the preview link, I was taken to this url instead, which in this case didn't work: https://www.debian.org/%257Esecretary/gr_initcoupling/tally.txt -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pumpa depends on: ii libaspell15 0.60.7~20110707-1.3 ii libc6 2.19-13 ii libgcc1 1:4.9.2-1 ii libqjson0 0.8.1-3 ii libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libstdc++6 4.9.2-1 ii libtidy-0.99-0 20091223cvs-1.4 pumpa recommends no packages. pumpa suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
