Bug#790525: FBTFS: No module named 'llfuse.capi'
Alright, I figured it out. s3ql is actually missing a build-dependency on python3-llfuse-dbg. It is probably pulled in indirectly in some circumstances. Thanks for the report! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790525: FBTFS: No module named 'llfuse.capi'
On Jun 30 2015, Martin Michlmayr t...@hp.com wrote: * Nikolaus Rath nikol...@rath.org [2015-06-29 21:02]: # python3-dbg Python 3.4.3+ (default, Jun 2 2015, 14:09:35) [GCC 4.9.2] on linux Type help, copyright, credits or license for more information. import llfuse import llfuse.capi In a sid chroot, I get: (sid)728:tbm@bl460gen8-30: ~/s3ql-2.13+dfsg] python3-dbg Python 3.4.3+ (default, Jun 2 2015, 14:09:35) [GCC 4.9.2] on linux Type help, copyright, credits or license for more information. import llfuse Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3/dist-packages/llfuse/__init__.py, line 13, in module from llfuse.capi import * ImportError: No module named 'llfuse.capi' (sid)733:tbm@bl460gen8-30: ~/s3ql-2.13+dfsg] dpkg -L python3-llfuse | grep dist-pa /usr/lib/python3/dist-packages /usr/lib/python3/dist-packages/llfuse /usr/lib/python3/dist-packages/llfuse/__init__.py /usr/lib/python3/dist-packages/llfuse/pyapi.py /usr/lib/python3/dist-packages/llfuse/capi.cpython-34m-x86_64-linux-gnu.so /usr/lib/python3/dist-packages/llfuse-0.40.egg-info /usr/lib/python3/dist-packages/llfuse-0.40.egg-info/PKG-INFO /usr/lib/python3/dist-packages/llfuse-0.40.egg-info/zip-safe /usr/lib/python3/dist-packages/llfuse-0.40.egg-info/top_level.txt /usr/lib/python3/dist-packages/llfuse-0.40.egg-info/dependency_links.txt Any idea? Very odd. I just tested it on two of my systems, and it works perfectly. It's also loaded from the same file that is present on your system: ~$ python3 Python 3.4.2 (default, Oct 8 2014, 10:45:20) [GCC 4.9.1] on linux Type help, copyright, credits or license for more information. import llfuse.capi llfuse.capi module 'llfuse.capi' from '/usr/lib/python3/dist-packages/llfuse/capi.cpython-34m-x86_64-linux-gnu.so' Could you try it with `strace -o log python3` and send me the logfile? Does it work outside the chroot (the jessie and sid versions of python3-llfuse are identical)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790525: FBTFS: No module named 'llfuse.capi'
sbuild (Debian sbuild) 0.65.2 (24 Mar 2015) on bl460gen8-30.hlinux.usa.hp.com ... python3 setup.py build_cython running build_cython /usr/lib/python3/dist-packages/Cython/Compiler/Main.py:514: UserWarning: got unknown compilation options, please remove: recursive, warning_errors warnings.warn(message) compiling src/s3ql/deltadump.pyx to src/s3ql/deltadump.c touch build_cython dh_testdir python3-dbg setup.py build -g Traceback (most recent call last): File setup.py, line 40, in module import s3ql File /«BUILDDIR»/s3ql-2.13+dfsg/src/s3ql/__init__.py, line 13, in module from llfuse import ROOT_INODE File /usr/lib/python3/dist-packages/llfuse/__init__.py, line 13, in module from llfuse.capi import * ImportError: No module named 'llfuse.capi' make[1]: *** [build-python] Error 1 Odd, it works fine in my chroot. Are you able to log into the sbuild chroot after the failed build? If so, could you try if the following works? # python3-dbg Python 3.4.3+ (default, Jun 2 2015, 14:09:35) [GCC 4.9.2] on linux Type help, copyright, credits or license for more information. import llfuse import llfuse.capi Thanks! -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790547: Running sbuild hangs after printing Summary
Package: sbuild
Version: 0.65.2-1
Severity: normal
I realize this is most likely a user error, but I could not find any
other forum to ask for help (is there an sbulid mailinglist somewhere?)
so I'm submitting this as a bug.
I'm trying to build a debian package, but when running it just hangs:
$ sbuild
[...]
╔══╗
║ python-llfuse 0.40+dfsg-2 (amd64) 29 Jun 2015 20:50 ║
╚══╝
Package: python-llfuse
Version: 0.40+dfsg-2
Source Version: 0.40+dfsg-2
Distribution: UNRELEASED
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
┌──┐
│ Summary │
└──┘
^C
If I enable debugging output (full log attached), the last output lines
are:
$ sbuild -D
[...]
'COLOUR_PREFIX' = '__SBUILD_COLOUR_27178:',
'This Space' = 0,
'OVersion' = '0.40+dfsg-2',
'Pkg Fail Stage' = 'init',
'Invalid Source' = 0,
'Install End Time' = 0
}, 'Sbuild::Build' );
There is no CPU activity at all.
-- System Information:
Debian Release: 8.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sbuild depends on:
ii adduser 3.113+nmu3
ii apt-utils 1.0.9.8
ii libsbuild-perl 0.65.2-1
ii perl5.20.2-3+deb8u1
Versions of packages sbuild recommends:
ii debootstrap 1.0.67
ii fakeroot 1.20.2-1
Versions of packages sbuild suggests:
ii deborphan 1.7.28.8-0.1
ii wget 1.16-1
-- no debconf information
D: Setting Log
File=/home/nikratio/in-progress/debian-packages/build-area/python-llfuse_0.40+dfsg-2_amd64-20150629-2044.build
D: Setting Log Stream=GLOB(0x36066e8)
sbuild (Debian sbuild) 0.65.2 (24 Mar 2015) on vostro.rath.org
╔══╗
║ python-llfuse 0.40+dfsg-2 (amd64) 29 Jun 2015 20:44 ║
╚══╝
Package: python-llfuse
Version: 0.40+dfsg-2
Source Version: 0.40+dfsg-2
Distribution: UNRELEASED
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
D: Setting Config=Sbuild::ConfBase=HASH(0x1f2f058)
D: Setting Chroots=HASH(0x3603138)
Found schroot chroot: chroot:cow
Aliases
Location
Name cow
Namespace chroot
Priority 0
Session Purged 0
Found schroot chroot: chroot:sid-amd64-sbuild
Aliases
Location
Name sid-amd64-sbuild
Namespace chroot
Priority 0
Session Purged 0
Found schroot chroot: source:cow
Aliases
Location
Name cow
Namespace source
Priority 0
Session Purged 0
Found schroot chroot: source:sid-amd64-sbuild
Aliases
Location
Name sid-amd64-sbuild
Namespace source
Priority 0
Session Purged 0
D: Setting Chroots=HASH(0x3603150)
D: Setting Pkg Status=failed
┌──┐
│ Summary │
└──┘
$job = bless( {
'Package' = 'python-llfuse',
'Build Start Time' = 0,
'Build Arch' = 'amd64',
'Package_OSVersion' = 'python-llfuse_0.40+dfsg-2',
'Lock Interval' = 5,
'Build Profiles' = '',
'Summary Stats' = {
'Machine Architecture' = 'amd64',
'Version' = '0.40+dfsg-2',
'Source-Version' = '0.40+dfsg-2',
'Package' = 'python-llfuse',
'Host Architecture' = 'amd64',
'Build Architecture' = 'amd64',
'Job' =
'/home/nikratio/in-progress/debian-packages/build-area/python-llfuse_0.40+dfsg-2.dsc'
},
'Source Dir' =
'/home/nikratio/in-progress/debian-packages/build-area',
'Session' = undef,
'Pkg Status' = 'failed',
'Chroot Build Dir' = '',
'Dependency Resolver' = undef,
'Max Lock Trys' = 120,
'Install Start Time' = 0,
'Package_SVersion' = 'python-llfuse_0.40+dfsg-2',
Bug#727060: Confirmed
I've the same problem, but setting nnimap-shell-program (or imap-shell-program, which is used to initialize the former) does not make any difference. -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785581: mercurial-git: Cloning fails with NotImplementedError
Package: mercurial-git
Version: 0.6.1-2
Severity: normal
Using the jessie package, I don't seem to be able to interact with git
repositories. Example:
$ hg clone git+http://git.gnus.org/cgit/gnus.git/
destination directory: gnus.git
** Unknown exception encountered with possibly-broken third-party extension git
** which supports versions 3.0.1 of Mercurial.
** Please disable git and try your action again.
** If that fixes the bug please report it to
https://bitbucket.org/durin42/hg-git/issues
** Python 2.7.9 (default, Mar 1 2015, 12:57:24) [GCC 4.9.2]
** Mercurial Distributed SCM (version 3.1.2)
** Extensions loaded: rebase, color, git, purge, strip, mq, histedit
Traceback (most recent call last):
File /usr/bin/hg, line 43, in module
mercurial.dispatch.run()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 28, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) 255)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 69, in
dispatch
ret = _runcatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 138, in
_runcatch
return _dispatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 839, in
_dispatch
cmdpats, cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 600, in
runcommand
ret = _runcommand(ui, options, cmd, d)
File /usr/lib/python2.7/dist-packages/mercurial/extensions.py, line 196, in
wrap
return wrapper(origfn, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/hgext/color.py, line 433, in colorcmd
return orig(ui_, opts, cmd, cmdfunc)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 930, in
_runcommand
return checkargs()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 901, in
checkargs
return cmdfunc()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 836, in
lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 550, in check
return func(*args, **kwargs)
File /usr/lib/python2.7/dist-packages/mercurial/commands.py, line 1331, in
clone
branch=opts.get('branch'))
File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 402, in clone
destpeer.local().clone(srcpeer, heads=revs, stream=stream)
File /usr/lib/python2.7/dist-packages/mercurial/localrepo.py, line 1730, in
clone
return self.pull(remote, heads)
File /usr/lib/python2.7/dist-packages/hgext/git/hgrepo.py, line 14, in pull
return self.githandler.fetch(remote.path, heads)
File /usr/lib/python2.7/dist-packages/hgext/git/git_handler.py, line 199,
in fetch
refs = self.fetch_pack(remote, heads)
File /usr/lib/python2.7/dist-packages/hgext/git/git_handler.py, line 1034,
in fetch_pack
ret = client.fetch_pack(path, determine_wants, graphwalker, f.write,
progress.progress)
File /usr/lib/python2.7/dist-packages/dulwich/client.py, line 1047, in
fetch_pack
raise NotImplementedError(self.send_pack)
NotImplementedError: bound method HttpGitClient.send_pack of
dulwich.client.HttpGitClient object at 0x7f7dd276b190
-- System Information:
Debian Release: 8.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mercurial-git depends on:
ii mercurial 3.1.2-2+deb8u1
ii python 2.7.9-1
ii python-dulwich 0.9.7-3
mercurial-git recommends no packages.
mercurial-git suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764557: Problem persists
Hello, Re-reading the bug log I think I haven't made clear this this is a recurring issue. Every few weeks my journal gets corrupted, and I have to remove the affected files. This happens even in the absence of any system crashes. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783578: shotwell: Shotwell doesn't start - /usr/lib/shotwell-settings-migrator: dconf: not found
Hi, dconf-cli was not installed. After installing it, it fails with $ shotwell ** ERROR:src/db/DatabaseTable.c:1269:database_table_add_column: assertion failed: (res == Sqlite.OK) Aborted Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783578: shotwell: Shotwell doesn't start - /usr/lib/shotwell-settings-migrator: dconf: not found
On Apr 29 2015, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: dconf-cli was not installed. After installing it, it fails with $ shotwell ** ERROR:src/db/DatabaseTable.c:1269:database_table_add_column: assertion failed: (res == Sqlite.OK) Aborted Is your shotwell a fresh install or an update/upgrade? It's a fresh install. But what you probably meant to ask is might there be pre-existing data from earlire shotwell versions in my home directory? Thhe answer to that is yes. Removing .local/share/shotwell, .cache/shotwell and .gconf/apps/shotwell works around the startup problem. I'm not that interested in debugging this further though (I already solved the problem at hand with a different tool), I just wanted to let you know that you have a missing dependency and maybe an upgrade problem. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783578: shotwell: Shotwell doesn't start - /usr/lib/shotwell-settings-migrator: dconf: not found
Package: shotwell Version: 0.20.1-1+b1 Severity: normal Hello, Trying to start shotwell gives me this: $ shotwell /usr/lib/shotwell-settings-migrator: 24: /usr/lib/shotwell-settings-migrator: dconf: not found /usr/lib/shotwell-settings-migrator: 27: /usr/lib/shotwell-settings-migrator: dconf: not found /usr/lib/shotwell-settings-migrator: 30: /usr/lib/shotwell-settings-migrator: dconf: not found ** ERROR:src/db/DatabaseTable.c:1269:database_table_add_column: assertion failed: (res == Sqlite.OK) Aborted $ -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages shotwell depends on: ii dbus-x111.8.16-1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libexif12 0.6.21-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgee-0.8-20.16.1-1 ii libgexiv2-2 0.10.2-2 ii libglib2.0-02.42.1-1 ii libgomp14.9.2-10 ii libgphoto2-62.5.4-1.1+b2 ii libgphoto2-port10 2.5.4-1.1+b2 ii libgstreamer-plugins-base1.0-0 1.4.4-2 ii libgstreamer1.0-0 1.4.4-2 ii libgtk-3-0 3.14.5-1 ii libgudev-1.0-0 215-17 ii libjavascriptcoregtk-3.0-0 2.4.8-2 ii libjson-glib-1.0-0 1.0.2-1 ii liblcms2-2 2.6-3+b3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libraw100.16.0-9+b1 ii librest-0.7-0 0.7.92-3 ii librsvg2-common 2.40.5-1 ii libsoup2.4-12.48.0-1 ii libsqlite3-03.8.7.1-1 ii libstdc++6 4.9.2-10 ii libwebkitgtk-3.0-0 2.4.8-2 ii libx11-62:1.6.2-3 ii libxml2 2.9.1+dfsg1-5 ii shotwell-common 0.20.1-1 shotwell recommends no packages. shotwell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763652: boot failure: similar case, possible explanation
On 04/22/2015 07:36 AM, chrysn wrote: it is my current impression that things fail when there are nested mount points, and the outer mount point needs a time-consuming fsck. nikolaus, is that plausible with your system? Yes, that's possible. I have a mount for /home as well as to mounts for /home/user/onething and /home/user/otherthing. Best, -Nikolaus -- Nikolaus Rath, Ph.D. Senior Scientist Tri Alpha Energy, Inc. +1 949 830 2117 ext 211 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781719: python-llfuse: -dbg packages do not include debugging symbols
Package: python-llfuse Version: 0.40-2+b2 Severity: normal The description of the python3-llfuse-dbg and python-llfuse-dbg packages claims that they contain debugging symbols as well as the extensions built for the debugging interpreter. However, it seems they only contain the latter. The .so's in the non-dbg packages are stripped though, so it seems that the debugging symbols are currently not available in any package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781652: python3-llfuse-dbg: fails to upgrade from 'testing' - trying to overwrite /usr/lib/python3/dist-packages/llfuse/capi.cpython-34dm-x86_64-linux-gnu.so
On Apr 01 2015, Andreas Beckmann a...@debian.org wrote: Preparing to unpack .../python3-llfuse-dbg_0.40+dfsg-1_amd64.deb ... Unpacking python3-llfuse-dbg (0.40+dfsg-1) over (0.40-2+b2) ... dpkg: error processing archive /var/cache/apt/archives/python3-llfuse-dbg_0.40+dfsg-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/llfuse/capi.cpython-34dm-x86_64-linux-gnu.so', which is also in package python3-llfuse 0.40-2+b2 This file should really only be in python3-llfuse-dbg (and in 0.40+dfsg-1 that's also the case). I'm not sure how it ended up in the wrong package in the earlier version, but I suspect a bug in one of the Python packaging helpers. I think the way to fix this is to add a Conflicts: (rather than Breaks: + Replaces:) on the old version, because the -dbg package does not replace the non-dbg package. Right? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780587: wheezy pbuilder fails to build some packages as tests involving network fail
Also, I see the exact same issue on my laptop, so it's not just happening on jenkins.debian.net - though granted, they both run stable and have been set up by me :-) Wild guess: could it be related to the kernel version? After all, it seems to be related to loopback networking... Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Bug#779474: debbindiff: hide temporary paths in html and text output when comparing tarballs
On Mar 02 2015, Jérémy Bobbio lunar-8fiuurrzop0dnm+yrof...@public.gmane.org wrote: Paul Wise: The output when directly comparing two tarballs contains the temporary paths used. This leaks the debbindiff user's TMP variable into the report and is also ugly. I suggest changing to just showing filenames. Current: /tmp/user/1000/tmpFsxqeVdebbindiff/flasm_1.62-6.debian.tar vs. /tmp/user/1000/tmpEVZZmydebbindiff/flasm_1.62-7.debian.tar Desired: flasm_1.62-6.debian.tar vs. flasm_1.62-7.debian.tar I am not sure what the use case is here. Without full path for the filenames at the top-level, there is no way to differentiate a report for two builds of the same source. As this is debbindiff primary purpose, I must admit I am a bit at loss. As you say, the primary purpose of debbindiff is to compare two builds of the same source. So why does the path matter at all? I think all that matters is the difference - it's not as if there's a newer and older version or something like that. In the case where debbindiff is used to compare different sources (as apparently done above), the filename alone contains the necessary information. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Bug#779380: debian-maintainers: Please add Nikolaus Rath nikol...@rath.org as a Debian Maintainer
Package: debian-maintainers Severity: normal Dear Maintainer, Please add Nikolaus Rath nikol...@rath.org to the keyring. The jetring changeset is attached. Best, -Nikolaus Comment: Add Nikolaus Rath nikol...@rath.org as a Debian Maintainer Date: Fri, 27 Feb 2015 13:47:18 -0800 Action: import Recommended-By: Petter Reinholdtsen p...@hungry.com, Piotr Ożarowski pi...@debian.org Agreement: https://lists.debian.org/debian-newmaint/2015/02/msg6.html Advocates: https://lists.debian.org/debian-newmaint/2015/02/msg8.html https://lists.debian.org/debian-newmaint/2015/02/msg00016.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFMiefoBEADYa1ZUqR/3YDqaf2UGpd9kNfKAY3TAR+xTcTYBKWTkJEy4cX2b ccSEOf7Ef1w0va+WgBwDUAllf+x21UFOWnPnqwb8LJxyg8dN3CRNWf9Z2vRXNOkv nAd0hYnA6xsbSLDQV0wpJOTH1zyZejMMWLpZh5SKRxaJAtpsfZ32qppzJhn4jJb0 v2fC+wJVkUy4mLe6yaHCrrHwlwldyzlwPBNwFfk31mVFYO+COSTGq+RXU2kCdujf w648IBYltdWI3D1vTilJd0gt2EDmOqQizfFJLlBTdLieJdrXzL4WWuzvJpC1Yadk mqMqnVkpcDxbxw0bK7G0faLigwWkshggaSns0vnpD05jQyMJUYdLwB9lh6u0B9AP cCxmPLhgHDdgdlZ+1JHMdfY0gIMSIAP2zkQu4iaTv5Tuc5a03dXE7G6GwZ+A5Ysr ovQCot2FY653A0swmAsaCy3A2OcVFXXgmZGLYh/06XA/+WhMSLVIaQ6eYTFgG9k8 iopU6zw5p2vav1rOuirymLe3b/VNZhk6nOpewwLp+5c2Ylmj6zEHegFQ9pbmlFF/ kubk9wGuS941G0/iLPyf3ePPhQ6hMY9L+7moW+Zlbqqg2XXa9S8C2rMwELDegpaw YJyMIt25xAb94BGMkU/SxclzZ62ktGkYrA0ekiHkB6zzt8uhHrGDxWEucQARAQAB tCFOaWtvbGF1cyBSYXRoIDxOaWtvbGF1c0ByYXRoLm9yZz6JAmEEEwEKAEsFAlMi efojGmh0dHA6Ly93d3cucmF0aC5vcmcvZ3BncG9saWN5Lmh0bWwCGwMFCRLMAwAF CwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQ0RP8rDxOWZ/peBAA077B1AWiKk42 pCJGMvD9pr4Cf2Kng4tm3HVxTHRcTZIU4i/2JRKDHpWlEKBVKNMip+mzIWE7bAl6 IaiiG+YbqdcAw434UocclpvczxayP/DuurcnZxII69F+OVllOrpZdmLls2m0QoP9 jUUsZ22C4JUp6ACQpo7NYlW9+ZzsY9cb90CR7K+oxE8RpCyqC+HqJXKYUa9EcnDa 9YGU98V7YCwTaHjxKcEvURx6YR02818UH0JiCB6CPxSMEkgWIM0z4kVbEeZ6wj4X 4c74RiIhcD4pg33K5DH55fYHtEDy8Q+bZHnLdtDMyF4GbvLddVESRBJUurUYpJ3X wwsf5vDZB0ypMYNegDXmcaSUovsxUyzJY6lR6wNG8MFSPlUdiHC/6D40FyMI9xx4 +KuNmKROqgfb5RUHiDPlvWSDqorDrAjaWooyrOAUJADURBcH2kAT3H0zaEFeKEDv DhCc4RUzNkFDxTGZIPJg/xQCFNN3d5H1mTKqzEFI+EnTq4RHLIXl93KFI4um+262 SKdhBeOwhPMgrT2LOVPrBGkBXubnv8odZPDBa84ZPgQ5npTmmQYshwDHic6seaXd korDOaqztnqOWkzxO/5bBI8wZSMuHUX7tRmDFOFT9w80h0WT18GtE2oWSWOaK5X8 sqIqfOOKevHYxAbzt7GTgUK+0EYwGiGJAUAEEAEKACoFAlMie5IjGmh0dHA6Ly93 d3cucmF0aC5vcmcvZ3BncG9saWN5Lmh0bWwACgkQttywLM0aUrlgiQf/fskwiyKt KS2ikqsiw6rqo9RP3A6AGJ3LQivpekV3elKxeu22L99yjkCEKHtggMmVd+Q9z9Pm vmx1d4EcVRtj7N86CcrQnPFbvUaiZ22gCDS61BCbnItzeo3nkOhbJtCU2AXHwBCx 2c1uGNzR5qJoymXo92FIp7JxKJ3hHZDWE2XnX41bNwzZtycfZuk5VB29MIiEIIGb R/Y8rq7KwWQdyQ8y5i6Jnq5hPqRVpvMagcA9ycOINkf6FqK0RHOjpxXgTHPjQudr lrhbbSOW5AQdsVGo+kJU/S+eYjPO1QLOAcVX1xDHmBIYUwY3wxIVUXUwiGScNuKH ATAwm8SFZuzTqIhqBBARCgAqBQJTInusIxpodHRwOi8vd3d3LnJhdGgub3JnL2dw Z3BvbGljeS5odG1sAAoJEKmtt/iuTkJc1LsAn38V2vwDN4A8pGgY3+KUVJvriRWC AJ40TcXYKtmKwfKMCUnaxb/mJFLUx4kCHAQQAQgABgUCVNw4rgAKCRAekxDZrc5g ZUqFD/44Ze4ow4ehRZ9P359WNwRKkOMmG/tMCq5boe6Sx+eon3dO8zlR6WZfRdlq bYWD4lUAN1H1zKbX/EmBcHiT01d4MAk3E3JqsmVKnhoEAj1D9/UryQlsLPuGgtbo coCxo2yg3dgTsbUiuOhYeRtp+zqdck55Y9awU1xi5MLHOryNyAtWqncxMSDF6e4R 17+RNUZqDykJQhjTAm2V+OQiWZ3ro15T0rYpy+2de5zCgZKKE3rZyaLYNjOaF3jR GvZfTRFyhsIyHxksoDfICUHayeTpHeLR6oczai14Eg6HG9TDDfNNEKOWNU6m1O9k SJ8Q+Ow+khVchSF6UY0gPl6o7SFukoybhm9A6WpRnGhgACUdX84jzMNydrf7yp9A qUWohmOth2GSc+owDoQCjuIFEjLJr0Ic+YFP0WD8ZMIrXhtG+muv0mE4qqo0JJgC 9rdZk9vt6SSzuA6Wg/Hb7lbkcNOwGysb2xnL5Czjqpl0LPfXGngYgQVLQ9Gf3x/E v4BIgnmzTxfCkTjRw2omL4mtCQJsajGLmwPNjX0SBKw57h8L6olljgrzzKZf6hV2 EGsTvfp9l1WJlLGD24WVUNnC0y4XlRO/zym1mCq8aLcnr+63BIsZZPvUToun7Pvg Iyxjtf3Y9FLKlh7IxzZzcWZT+GJg0eLd2JMUrSE07jSn8Ot7N4kCHAQQAQgABgUC VN/l8gAKCRAWf9Q0wEOjE1iVEADAQPNGvhvvVMONiYZ3hIfv2Te7yOIWduPtvzyk XovK+pzwwFdGs0BqreVMo7dnONecj53svvRwHU1XD/oMDDYVXfy5mfmM4ffIID77 tA37bVblMApkwFWm573oaTFJhHH6VkI9Kb1/ST4wl9T8QdJrMkrdkr/2ypl6AHOF uI1A+VuAAKooZ34outAdzZgFBZEobBgHcZEwatarNLP+bl6b1U8rYFUeKra9pFEc IIOEfa+OVumtPyh6bue2CBrhgCh1EhiF9sD8PxxGzx9ZH2wsgUfXwKVmoE/bDsuW P7HJkpRFWRHeDgqohVCwUXqFaqwq4up6dWm0Js/wbZp87kzFaMjzTp98Nr3akNRO 636MXxNip6JHNNxGuI5TAbXGXG3Foh5b57bOfS3zc/g4328/6ehA+DDct+aBlrhE fSYGdZ3Ss28IRcsxY9Xpx1ouKXY3g51pJYzTTrLCQ28YVV3ImvzA6Pi6vaSrIoCt HfNqONloGo3QF/1zleAGFGz0AmVCckTDk/QvxYG842LjMjtkXhsZpLUUmEE11ore 6ZaFqDcWba/Ob81/Cp9yibp8WNyO2kj5vs6peStTp0mPoPbWmX+43QAYcoIeVceP gizDpk84+esn2XX/NbK0vE+eNXZF2oxUsOBjoWbezD1X7+Ymz40Ry5H5OuaCwkkR 0Id37LkCDQRTInn6ARAAwL+oAUxGacCUctUxjdInq+HK/9EYV1KDOgsUV6JQfMF8 nTJNXEYg8xsi7BXGtBf0JL0n4TyVnVGBS2vaR3c4+xCvTTxEyOcgqyVeKp1Hh61w QYbnlbhANrT2dKItG/dwgZHVeDfW1ARrgsBFF7L97OuHruipK8n9ibPruPS4szGM rBS6Fvdt1bPX258D1Y5Z2MrvQkjAOlynIKrgxMC1BiFNUH6ktukXmKgbpiPG8ZuZ Bk+60e2IkvXB5gp5dcNvJ0hd1xWpuMJeThUdwwQqA79Kf7LStmltqlbphGzbAMQy 7DJBJpHMm55HwG6AUMDuDh9H1cLs891a5wyPgGzHFMlMUy3hJMI/LZO4L/oxRidF cRrPsIaXWP8Ot85no3+QguQNRiuNNDTLZv8L+ExNBDHfVbg9gdqZr0gfZQHBQIE2 7XHfOvc7z7PMd2BtsGM/kKh3UTAZfgiZSgZSOZAOBRqb6dG2nTqxi+tTN0lhStQl 9TpN39NqMa9NJPjzzRU2dLdTRVX
Bug#778633: dh_python3: how to use .pydist file?
On Feb 17 2015, Nikolaus Rath nikol...@rath.org wrote:
On Feb 17 2015, Piotr Ożarowski pi...@debian.org wrote:
[Ben Finney, 2015-02-17]
The question remains, though: where should that fact (and many others
like it) be documented so newcomers don't have to keep asking?
I guess dependencies section in dh.python{2,3} manpage should be more
clear that README.PyDist is about .pydist and pydist-overrides files.
Patches are welcome.
Already done after your first response (#778633) :-).
Here's a revised patch that also documents the format of the
py3dist-overrides file:
diff --git a/dh_python3.rst b/dh_python3.rst
--- a/dh_python3.rst
+++ b/dh_python3.rst
@@ -38,14 +38,38 @@
dependencies
-dh_python3 tries to translate Python dependencies from requires.txt file to
-Debian dependencies. Use debian/py3dist-overrides or --no-guessing-deps option
-to override it if the guess is incorrect. If you want dh_python3 to generate
-more strict dependencies (f.e. to avoid ABI problems) create
-debian/python3-foo.pydist file. See /usr/share/doc/dh-python/README.PyDist
-for more information. If the pydist file contains PEP386 flag or set of (uscan
-like) rules, dh_python3 will make the depedency versioned (version requirements
-are ignored by default).
+
+dh_python3 tries to translate Python dependencies from the
+`requires.txt` file to Debian dependencies. In many cases, this works
+without any additional configuration because dh_python3 comes with a
+build-in mapping of Python module names to Debian packages that is
+periodically regenerated from the Debian archive. By default, the
+version information in the Python dependencies is discarded. If you
+want dh_python3 to generate more strict dependencies (e.g. to avoid
+ABI problems), or if the automatic mapping does not work correctly for
+your package, you have to provide dh_python3 with additional rules for
+the translation of Python module to Debian package dependencies.
+
+For a package *python3-foo* that depends on a package *python3-bar*,
+there are two files that may provide such rules:
+
+#. If the *python3-foo* source package ships with a
+ `debian/py3dist-overrides` file, this file is used by dh_python3
+ during the build of *python3-foo*.
+
+#. If the *python3-bar* source package ships with a
+ `debian/python3-bar.pydist` file (and uses dh_python3), this file
+ will be included in the binary package as
+ `/usr/share/dh-python/dist/cpython3/python3-bar`. During the build
+ of *python3-foo*, dh_python3 will then find and use the file.
+
+Both files have the same format described in
+`/usr/share/doc/dh-python/README.PyDist`. If all you want is to
+generate versioned dependencies (and assuming that the *python3-bar*
+package provides the *pybar* Python module), in most cases it will be
+sufficient to put the line ``pybar python3-bar; PEP386`` into either
+of the above files.
+
private dirs
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
Bug#778633: dh-python: Clarify purpose of .pydist files
Package: dh-python Version: 1.2014-2 Severity: wishlist The dh_python3 manpage and the README.PyDist file currently do not make it clear that .pydist files are for use by *other* packages when they want to depend on the package that ships the .pydist file. A possible patch is attached. diff --git a/dh_python3.rst b/dh_python3.rst --- a/dh_python3.rst +++ b/dh_python3.rst @@ -38,14 +38,20 @@ dependencies -dh_python3 tries to translate Python dependencies from requires.txt file to -Debian dependencies. Use debian/py3dist-overrides or --no-guessing-deps option -to override it if the guess is incorrect. If you want dh_python3 to generate -more strict dependencies (f.e. to avoid ABI problems) create -debian/python3-foo.pydist file. See /usr/share/doc/dh-python/README.PyDist -for more information. If the pydist file contains PEP386 flag or set of (uscan -like) rules, dh_python3 will make the depedency versioned (version requirements -are ignored by default). + +dh_python3 tries to translate Python dependencies from requires.txt +file to Debian dependencies. Use debian/py3dist-overrides +or --no-guessing-deps option to override it if the guess is +incorrect. Dependencies are not versioned by default. If you want +dh_python3 to generate more strict dependencies (f.e. to avoid ABI +problems) on your package, you can create a debian/python3-foo.pydist +file. This file will be installed in +`/usr/share/dh-python/dist/cpython3/binary_pkg_name`, and other +packages using dh_python3 will use it to determine the correct +dependency on `binary_pkg_name` during build. If the pydist file +contains a PEP386 flag or set of (uscan like) rules, dh_python3 will +make the dependency versioned. See +`/usr/share/doc/dh-python/README.PyDist` for more information. private dirs
Bug#778487: s3ql: Needs python-dugong = 3.4
So please tighten the dependencies of s3ql 2.13 to require python3-dugong = 3.4 At least according to https://packages.debian.org/source/unstable/s3ql, this is exactly what the dependency is. Where did you get the package from? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778487: s3ql: Needs python-dugong = 3.4
On Feb 16 2015, Mika Pflüger deb...@mikapflueger.de wrote: Hi Nikolaus, Am Mon, 16 Feb 2015 09:42:57 -0800 schrieb Nikolaus Rath nikol...@rath.org: So please tighten the dependencies of s3ql 2.13 to require python3-dugong = 3.4 At least according to https://packages.debian.org/source/unstable/s3ql, this is exactly what the dependency is. That shows the dependencies of the s3ql source package (I guess that's [...] So I guess dh_python3 needs a pydist file or a py3dist-overrides file. Adding debian/s3ql.pydist with the contents dugong python3-dugong; PEP386 Gotcha. Thanks for doing all the debugging for me. It'll be fixed in the next release (I'd upload a fixed version right away if I could, but I don't want to bother my sponsor with too many minor uploads). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Bug#778487: s3ql: Needs python-dugong = 3.4
On Feb 16 2015, Mika Pflüger deb...@mikapflueger.de wrote:
Hi Nikolaus,
Am Mon, 16 Feb 2015 09:42:57 -0800
schrieb Nikolaus Rath nikol...@rath.org:
So please tighten the dependencies of s3ql 2.13 to require
python3-dugong = 3.4
At least according to
https://packages.debian.org/source/unstable/s3ql, this is exactly
what the dependency is.
That shows the dependencies of the s3ql source package (I guess that's
build dependencies, but I'm not sure about that). The dependencies of
the s3ql binary packages are found at
https://packages.debian.org/sid/s3ql
and as you can see, there is no version specified for python3-dugong. I
think the ${python3:Depends} does not expand to versioned dependencies
by default. The dh_python3 man page says:
If the pydist file contains PEP386 flag or set of (uscan like) rules,
dh_python3 will make the depedency versioned (version requirements are
ignored by default).
So I guess dh_python3 needs a pydist file or a py3dist-overrides file.
Adding debian/s3ql.pydist with the contents
dugong python3-dugong; PEP386
did not do the trick for me, maybe I'm reading the manpage wrong.
However; I couldn't test building in a clean environment because
building s3ql failed for me (with and without the pydist file) in an
unstable pbuilder. I still think a proper pydist file should work.
The above didn't work in a clean chroot for me either (but the
build succeeds). But I agree that it should work that way. I'll look
into it.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
signature.asc
Description: PGP signature
Bug#771969: Workaround
This is tracked upstream at https://bitbucket.org/nikratio/s3ql/issue/110/improve-handling-of-name-resolution -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776684: postfix: Postfix does not start after installation
Package: postfix Version: 2.11.3-1 Severity: normal Hello, I installed postfix with apt-get, selected No configuration. Then I created a custom main.cf file and tried to start the service. However: # systemctl start postfix Failed to start postfix.service: Unit postfix.service failed to load: No such file or directory. # systemctl status postfix ● postfix.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # service postfix start Failed to start postfix.service: Unit postfix.service failed to load: No such file or directory. I was able to start postfix by manually calling /usr/sbin/postfix start, but that's obviously not the way it ought to work. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postfix depends on: ii adduser3.113+nmu3 ii cpio 2.11+dfsg-4 ii debconf [debconf-2.0] 1.5.55 ii dpkg 1.17.23 ii libc6 2.19-13 ii libdb5.3 5.3.28-7~deb8u1 ii libsasl2-2 2.1.26.dfsg1-12 ii libsqlite3-0 3.8.7.1-1 ii libssl1.0.01.0.1k-1 ii lsb-base 4.1+Debian13+nmu1 ii netbase5.3 ii ssl-cert 1.0.35 Versions of packages postfix recommends: ii python 2.7.8-2 Versions of packages postfix suggests: ii bsd-mailx [mail-reader] 8.1.2-0.20141216cvs-1 pn dovecot-common none ii emacs24 [mail-reader]24.4+1-4.1 ii icedove [mail-reader]31.3.0-1 ii libsasl2-modules 2.1.26.dfsg1-12 ii mutt [mail-reader] 1.5.23-3 pn postfix-cdb none pn postfix-doc none pn postfix-ldap none pn postfix-mysqlnone pn postfix-pcre none pn postfix-pgsqlnone pn procmail none pn resolvconf none pn sasl2-binnone pn ufw none -- debconf information: postfix/sqlite_warning: postfix/chattr: false postfix/rfc1035_violation: false postfix/protocols: postfix/kernel_version_warning: postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/recipient_delim: + postfix/procmail: postfix/destinations: postfix/bad_recipient_delimiter: postfix/root_address: postfix/tlsmgr_upgrade_warning: postfix/relayhost: postfix/relay_restrictions_warning: * postfix/main_mailer_type: No configuration postfix/mailbox_limit: 0 postfix/not_configured: postfix/retry_upgrade_warning: postfix/mailname: /etc/mailname postfix/mydomain_warning: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776685: postfix: Does not honor smtp_host_lookup
Package: postfix Version: 2.11.3-1 Severity: normal If I understand correctly, setting smtp_host_lookup dns,native should allow postfix to resolve hostnames from /etc/hosts if they are not resolvable via DNS. However, this does not seem to work in practice: [0] root@thinkpad:/etc/postfix# grep lookup main.cf smtp_host_lookup = dns,native [0] root@thinkpad:/etc/postfix# /usr/sbin/postfix reload postfix/postfix-script: refreshing the Postfix mail system [0] root@thinkpad:/etc/postfix# echo test | mailx nikol...@rath.org [0] root@thinkpad:/etc/postfix# mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- D617DC0AE3 266 Sat Jan 31 00:07:23 r...@thinkpad.rath.org (Host or domain name not found. Name service error for name=ebox type=A: Host not found, try again) nikol...@rath.org -- 0 Kbytes in 1 Request. [0] root@thinkpad:/etc/postfix# ping ebox PING ebox (192.168.12.1) 56(84) bytes of data. 64 bytes from ebox (192.168.12.1): icmp_seq=1 ttl=64 time=15.7 ms -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postfix depends on: ii adduser3.113+nmu3 ii cpio 2.11+dfsg-4 ii debconf [debconf-2.0] 1.5.55 ii dpkg 1.17.23 ii libc6 2.19-13 ii libdb5.3 5.3.28-7~deb8u1 ii libsasl2-2 2.1.26.dfsg1-12 ii libsqlite3-0 3.8.7.1-1 ii libssl1.0.01.0.1k-1 ii lsb-base 4.1+Debian13+nmu1 ii netbase5.3 ii ssl-cert 1.0.35 Versions of packages postfix recommends: ii python 2.7.8-2 Versions of packages postfix suggests: ii bsd-mailx [mail-reader] 8.1.2-0.20141216cvs-1 pn dovecot-common none ii emacs24 [mail-reader]24.4+1-4.1 ii icedove [mail-reader]31.3.0-1 ii libsasl2-modules 2.1.26.dfsg1-12 ii mutt [mail-reader] 1.5.23-3 pn postfix-cdb none pn postfix-doc none pn postfix-ldap none pn postfix-mysqlnone pn postfix-pcre none pn postfix-pgsqlnone pn procmail none pn resolvconf none pn sasl2-binnone pn ufw none -- debconf information: postfix/sqlite_warning: postfix/mailbox_limit: 0 postfix/relayhost: postfix/mailname: /etc/mailname postfix/relay_restrictions_warning: postfix/procmail: postfix/bad_recipient_delimiter: postfix/chattr: false postfix/destinations: postfix/tlsmgr_upgrade_warning: * postfix/main_mailer_type: No configuration postfix/kernel_version_warning: postfix/not_configured: postfix/recipient_delim: + postfix/mydomain_warning: postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 postfix/protocols: postfix/rfc1035_violation: false postfix/root_address: postfix/retry_upgrade_warning: # Basic config myhostname=thinkpad mydomain=rath.org append_dot_mydomain = yes # Local delivery for: mydestination = $myhostname $myhostname.$mydomain localhost # Only relay from local mynetworks_style = host allow_percent_hack = no backwards_bounce_logfile_compatibility = no default_process_limit = 3 delay_warning_time = 24h mailbox_size_limit = 51200 message_size_limit = 6400 parent_domain_matches_subdomains = no inet_protocols = ipv4 # Smarthost smtp_use_tls = yes # Brackets: Don't use MX entry relayhost = [ebox]:587 #relayhost = 192.168.12.1:587 smtp_host_lookup = dns,native smtp_tls_cert_file = /etc/postfix/client.crt smtp_tls_key_file = /etc/postfix/client.key smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_tls_loglevel = 0 # Allow plain login smtp_sasl_security_options = # No NIS alias_maps = hash:/etc/aliases readme_directory = /usr/share/doc/postfix html_directory = /usr/share/doc/postfix/html
Bug#776157: /usr/bin/evince: Printing some PDFs produces blank page
Package: evince-gtk Version: 3.14.1-1 Severity: normal File: /usr/bin/evince evince seems to be unable to print some PDFs. A print job is sent to the printer, but the printer then prints only blank pages. I have attached an example of such a PDF. The same PDF prints fine from acroread, and is rendered fine by evince on the screen. Other PDFs print fine from evince as well. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages evince-gtk depends on: ii evince-common 3.14.1-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libevdocument3-4 3.14.1-1 ii libevview3-3 3.14.1-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk-3-0 3.14.5-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libxml22.9.1+dfsg1-4 ii shared-mime-info 1.3-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages evince-gtk recommends: ii dbus-x11 1.8.12-3 Versions of packages evince-gtk suggests: ii gvfs 1.22.2-1 pn nautilus none ii poppler-data 0.4.7-1 pn unrar none -- no debconf information receipt.pdf Description: Adobe PDF document
Bug#762194: Initial draft of affirming transition to systemd as default for #762194
[ Resending to bug address rather than just ctte list ] Don Armstrong d...@debian.org writes: On Wed, 10 Dec 2014, Nikolaus Rath wrote: Don Armstrong d...@debian.org writes: 4. The CTTE appreciates the effort of Debian contributors to mitigate any issues with the transition by: a) Providing a fallback boot entry for sysvinit when systemd is the default init in grub (#757298) b) Developing a mechanism to warn on non-standard inittab configurations which are unsupported in systemd. Does this deliberately say just inittab instead of something like non-compatible configurations? Yes. I believe (and hope) that similar mechanism are planned in particular for fstab and crypttab. It would be awesome if they are; I'd like to point to specific bugs for these if you're aware of them. [My motivation here is to try to get people who have these kinds of setups to participate in those bugs.] Not sure if I understand you correctly, because they're easy enough to find. But anyway, here are some examples: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771492 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747258 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765594 Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762194: Initial draft of affirming transition to systemd as default for #762194
Don Armstrong d...@debian.org writes: 4. The CTTE appreciates the effort of Debian contributors to mitigate any issues with the transition by: a) Providing a fallback boot entry for sysvinit when systemd is the default init in grub (#757298) b) Developing a mechanism to warn on non-standard inittab configurations which are unsupported in systemd. Does this deliberately say just inittab instead of something like non-compatible configurations? I believe (and hope) that similar mechanism are planned in particular for fstab and crypttab. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: Workaround
As a workaround, could you use the attached program instead of mount.s3ql? It should work just like mount.s3ql, but it will retry on any kind of DNS error. I'm still planning to fix this properly (probably by not retrying on the first resolution attempt), but that is going to take a while. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« #!/usr/bin/env python3 import sys sys.path.insert(0, '/usr/lib/s3ql') import s3ql.logging import dugong is_temp_network_error_real = dugong.is_temp_network_error def is_temp_network_error(exc): if isinstance(exc, dugong.HostnameNotResolvable): return True return is_temp_network_error_real(exc) dugong.is_temp_network_error = is_temp_network_error import s3ql.mount s3ql.mount.main(sys.argv[1:])
Bug#771942: now in unstable
Control: tags -1 -moreinfo The package is now in unstable. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Shannon Dealy de...@deatech.com writes: On Thu, 4 Dec 2014, Nikolaus Rath wrote: Shannon Dealy de...@deatech.com writes: [snip] Unfortunately Linux does not provide an easy way to distinguish between an unavailable DNS server, and an un-resolvable host name. To distinguish these cases, S3QL/Dugong attempts to resolve a number of test hostnames. If these resolve, but the S3 hostname does not, S3QL/Dugong concludes that this hostname is not resolvable and terminates. Otherwise it assumes that the DNS server is currently not reachable and retries. Attempting to resolve hostnames on your system frequently fails (sometimes 3 times in a row), and sometimes it's apparently sufficiently flaky that 1. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved 2. Any of google.com, iana.org, or root-servers.net can be resolved 3. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved in this order, and without any waiting times. At this point, S3QL thus assumes that your bucket ceased to exist and terminates. To avoid this, you'll have to fix the DNS resolution issues on your system. Maybe install a caching proxy nameserver like dnsmasq? While I can try dnsmasq as a solution, I was not having the degree of problems I am seeing under the old version of s3ql, and this is not the only network I connect to where I am seeing these problems. This could simply mean one or more of: - the network(s) have become more unstable (certainly possible) - that S3QL's test doesn't work quite the same way as before - there is a bug somewhere (S3QL or python libraries - I had to upgrade python to install the new S3QL) that makes it appear that DNS is still broken after it recovers - or something else is going on. The relevant code in S3QL 2.2 was last touched in version 2.2, so I don't think that's it. However, relevant code in Dugong was last modified in version 3.2. Prior to 3.2, *any* DNS problem was considered temporary. In 3.2 and later, DNS problems are only considered temporary of *no* hostname can be resolved. The problem with the prior behavior was that it would permanently retry even in situations like this: mkfs.s3ql s3://mybucket.aws.s3.cmo Having this command block for any significant amount of time in the hope that the wrong hostname becomes resolvable was rather surprising, and people complained that their scripts would just hang instead of properly reporting an error. It seems for you the situation is the other way around... I see in the log I sent you that a few failures were reported 10 minutes before S3QL gave up, but it is not clear to me if S3QL was able to resolve DNS names between these. Am I correct in assuming that there a timer as well as the three time in a row failure limit you mentioned? There's no limit on the number of retries. After the 3rd retry, S3QL starts to emit log messages. The time interval between the retries is increasing over time. However, all this happens only if the DNS server is unreachable. If the DNS server is apparently reachable, but unable to resolve the hostname, no retrying is done. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Shannon Dealy de...@deatech.com writes: The relevant code in S3QL 2.2 was last touched in version 2.2, so I don't think that's it. However, relevant code in Dugong was last modified in version 3.2. Prior to 3.2, *any* DNS problem was considered temporary. In 3.2 and later, DNS problems are only considered temporary of *no* hostname can be resolved. The problem with the prior behavior was that it would permanently retry even in situations like this: mkfs.s3ql s3://mybucket.aws.s3.cmo Having this command block for any significant amount of time in the hope that the wrong hostname becomes resolvable was rather surprising, and people complained that their scripts would just hang instead of properly reporting an error. It seems for you the situation is the other way around... Which proves once again that you just can't win in life :-) Given the senario you were trying to fix with the change, perhaps a better approach would be to fail if initial resolution fails, but if the initial resolution succeeds, then the end point can reasonably be assumed to exist and future failures should keep retrying, at least for a substantial (possibly configurable) period of time. This provides the immediate feedback for manual or scripting related interactions, but once the file system is mounted focuses on maintaining/recovering the connection. Yes, that would be the best solution. It's just ugly to code, either way you to pass a do_not_fail parameter all the way from the main function to the low level network routines, or you have to do the first lookup on a higher level (which then needs to know details about all the storage backends). Personally, I would love it if I could simply keep the file system mounted at all times, even when there is no network link, so that when there is a connection I can simply start using it, and when the connection goes away (even for a day or two), everything blocks and simply picks up where it left off when the connection returns. Well, that should actually work already. When there is no network connection, s3ql retries for a long amount. The problem only arises if there is partial connectivity. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Shannon Dealy de...@deatech.com writes: At least at the time that you issued the kill command, mount.s3ql was busy doing the SSL handshake with the remote server, so while it looked like it was hanging, it was probably waiting for the remote server. It had been waiting a very long time, though I don't remember exactly, for this case. I have limited the cache to 1GB so I don't have to wait too long if I need to kill a backup, pack up the computer and leave. Because of this, I know from past experience the maximum amount of time it takes to flush the cache and unmount using this network. I figure it is dead if the network has remained up, but network and cpu load for this process are minimal to zero and it has taken more than twice as long as it should for the unmount. In this case it should be done in 15 to 20 minutes max, so figure it had been at least twice that. Sorry I don't have a better answer. If you have a suggestion for a better way to tell if the filesystem is hung, it would be helpful. On one occasion I let a hung system sit for hours to see if it would recover (it didn't) The only truly reliable way is to generate a stacktrace (as you've done) and check if any threads are blocked in a read/recv/write/send syscall. If not, the file system hangs. If they are, then it's waiting for the remote server. Unfortunately S3QL's TCP timeout setting only applies after the SSL handshake, so the handshake can last as long as the Linux TCP stack allows... Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772052: (s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system)
On 12/04/2014 10:07 AM, Shannon Dealy wrote: Attached is the log file for a failed unmount. While my previous attempts were simple umount.s3ql commands, this time a couple of additional commands were run after rsync completed and before the umount: s3qlctrl flushcache /media/server-external s3qlctrl upload-meta /media/server-external umount.s3ql /media/server-external The logs looks as you also send a SIGUSR1 signal to mount.s3ql. Is that correct? After the umount.s3ql command, what are the contents of /root/.s3ql/local:=2F=2F=2Fmedia=2FTransferDrive=2FS3QL_server-external-cache? Can you confirm that this directory did not exist when calling mount.s3ql? Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772052: (s3ql: umount.s3ql throws exception on s3ql file system mounted via sshfs file system)
retitle 772052 mount.s3ql crashes on unmount if there are stale cache files thanks On 12/04/2014 11:41 AM, Shannon Dealy wrote: On Thu, 4 Dec 2014, Nikolaus Rath wrote: On 12/04/2014 10:07 AM, Shannon Dealy wrote: Attached is the log file for a failed unmount. While my previous attempts were simple umount.s3ql commands, this time a couple of additional commands were run after rsync completed and before the umount: s3qlctrl flushcache /media/server-external s3qlctrl upload-meta /media/server-external umount.s3ql /media/server-external The logs looks as you also send a SIGUSR1 signal to mount.s3ql. Is that correct? No, it ran to completion on its own (though it took forever). What do you mean by that? Sending SIGUSR1 should not affect completion of the command at all. I forgot to mention that I did issue this command just before running umount.s3ql setfattr -n fuse_stacktrace /media/server-external Yeah, sorry, that's actually also what the logs say. Both the setfattr and the kill -SIGUSR commands just cause mount.s3ql to print a stack trace (though the mechanism is slightly different). though I am not sure if that makes any difference with fuse as that command had previously been issued for that mount point when a different file system (the other one we have been debugging) was mounted there, and I have no idea if fuse retains this setting between unmounts and mounts on a given mount point. No, that's not a setting. It's a one-off command. After the umount.s3ql command, what are the contents of /root/.s3ql/local:=2F=2F=2Fmedia=2FTransferDrive=2FS3QL_server-external-cache? Can you confirm that this directory did not exist when calling mount.s3ql? No, in fact based on the timestamps, I can confirm that this directory did exist as it has over 4000 files in it with November 30th timestamps spanning roughly 1/2 hour. I never gave this directory a thought as the mount indicates that the cache is out of date, so I assumed any old data that was lying around would be discarded when it downloads the current file system info. That's the reason for the exception on umount then. mount.s3ql currently isn't able to handle that. The existing data is ignored as you say, but mount.s3ql attempts to rmdir the cache directory after unmounting. That fails if there are still files in there. Normally, the only way for this directory to exist is if the file system was not unmounted cleanly. In this case mount.s3ql will refuse to start, and you have to run fsck.s3ql instead. fsck.s3ql will then clean-up the cache directory, and mount.s3ql will start with an empty cache. In your case... It should be noted that the fsck run on this file system was not run from my local machine, but from the remote server, so when I mount this on my local machine, it says something to the effect that the local cache is out of date, and then proceeds to download and unpack the current file system information from the remote server. .. you have neatly circumvented the clean-up of the cache directory. mount.s3ql now believes the file system is clean, but there is actually a cache directory with files in it. This is certainly a bug in S3QL, but I have to think about what the correct behavior for mount.s3ql actually would be. Refusing to mount would be odd, because the file system is indeed clean. But silently deleting the data in there intuitively sounds like a dangerous choice as well. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
On 12/03/2014 11:44 PM, Shannon Dealy wrote: the file system still hangs (or the next time it hangs), could you follow the instructions at https://bitbucket.org/nikratio/s3ql/wiki/Providing%20Debugging%20Info to obtain a Python stacktrace, and attach it to this issue? This time the file system didn't hang until I attempted to unmount it. Attached are two log files with the mount and stack trace information. This looks odd. Did you issue both setfattr -n fuse_stacktrace *and* kill -s USR1 commands? The attached files indicate both, and moreover, the number of active threads during the kill -s USR1 command was much lower than during the setfattr command. How much time did pass between these commands (assuming that you issued both)? At least at the time that you issued the kill command, mount.s3ql was busy doing the SSL handshake with the remote server, so while it looked like it was hanging, it was probably waiting for the remote server. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Shannon Dealy de...@deatech.com writes: I installed python-dugong from experimental and proceeded to transfer a lot of data to my S3 file system. Stopped it a couple of times, unmounted once (successfully), remounted and continued transferring data. After around 13-15 GB total had been uploaded, the file system crashed again (no hang): [...] See attached mount log file for more details. [...] 2014-12-05 00:18:35.346 31446:Thread-3 (name)s.wrapped: Encountered DNSUnavailable exception (Unable to resolve server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com, DNS server unavailable.), retrying call to ObjectW.close for the 3-th time... [...] File /usr/lib/python3/dist-packages/dugong/__init__.py, line 1449, in create_socket raise HostnameNotResolvable(address[0]) dugong.HostnameNotResolvable: Host server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com does not have any ip addresses Unfortunately Linux does not provide an easy way to distinguish between an unavailable DNS server, and an un-resolvable host name. To distinguish these cases, S3QL/Dugong attempts to resolve a number of test hostnames. If these resolve, but the S3 hostname does not, S3QL/Dugong concludes that this hostname is not resolvable and terminates. Otherwise it assumes that the DNS server is currently not reachable and retries. Attempting to resolve hostnames on your system frequently fails (sometimes 3 times in a row), and sometimes it's apparently sufficiently flaky that 1. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved 2. Any of google.com, iana.org, or root-servers.net can be resolved 3. server-external-2014-11-21-deatech-com-s3ql.s3.amazonaws.com cannot be resolved in this order, and without any waiting times. At this point, S3QL thus assumes that your bucket ceased to exist and terminates. To avoid this, you'll have to fix the DNS resolution issues on your system. Maybe install a caching proxy nameserver like dnsmasq? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771942: unblock: python-dugong/3.3+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-dugong as discussed with Niels Thykier
in private mail.
Changelog:
python-dugong (3.3+dfsg-3) unstable; urgency=medium
* The `is_temp_network_error` function now knows about more kinds of
temporary errors, in particular also about those that do not have a
corresponding Python exception (e.g. no route to host).
Closes: #771756.
-- Nikolaus Rath nikol...@rath.org Wed, 03 Dec 2014 09:11:52 -0800
Debdiff against testing is attached.
The package is not yet uploaded because I'm waiting for a sponsor.
unblock python-dugong/3.3+dfsg-3
diff -Nru python-dugong-3.3+dfsg/debian/changelog python-dugong-3.3+dfsg/debian/changelog
--- python-dugong-3.3+dfsg/debian/changelog 2014-11-15 05:44:37.0 -0800
+++ python-dugong-3.3+dfsg/debian/changelog 2014-12-03 09:12:38.0 -0800
@@ -1,3 +1,13 @@
+python-dugong (3.3+dfsg-3) unstable; urgency=medium
+
+ * The `is_temp_network_error` function now knows about more kinds of
+temporary errors, in particular also about those that do not have a
+corresponding Python exception (e.g. no route to host).
+
+Closes: #771756.
+
+ -- Nikolaus Rath nikol...@rath.org Wed, 03 Dec 2014 09:11:52 -0800
+
python-dugong (3.3+dfsg-2) unstable; urgency=medium
* Skip unit tests in test/test_examples.py. These tests require network
diff -Nru python-dugong-3.3+dfsg/debian/patches/bug_771756.diff python-dugong-3.3+dfsg/debian/patches/bug_771756.diff
--- python-dugong-3.3+dfsg/debian/patches/bug_771756.diff 1969-12-31 16:00:00.0 -0800
+++ python-dugong-3.3+dfsg/debian/patches/bug_771756.diff 2014-12-03 09:15:42.0 -0800
@@ -0,0 +1,30 @@
+Description: Fix bug #771756
+Author: Nikolaus Rath nikol...@rath.org
+Forwarded: not-needed
+Origin: upstream, https://bitbucket.org/nikratio/python-dugong/commits/36dc1863633b6fe38a02e5ba07dd3b0cf5deeb0f
+Last-Update: 2014-12-03
+
+--- a/dugong/__init__.py
b/dugong/__init__.py
+@@ -1394,8 +1394,20 @@
+ return False
+ return True
+
+-return False
++elif isinstance(exc, OSError):
++# We have to be careful when retrieving errno codes, because
++# not all of them may exist on every platform.
++for errcode in ('EHOSTDOWN', 'EHOSTUNREACH', 'ENETDOWN',
++'ENETRESET', 'ENETUNREACH', 'ENOLINK',
++'ENONET', 'ENOTCONN', 'ENXIO', 'EPIPE',
++'EREMCHG', 'ESHUTDOWN', 'ETIMEDOUT'):
++try:
++if getattr(errno, errcode) == exc.errno:
++return True
++except AttributeError:
++pass
+
++return False
+
+ class CaseInsensitiveDict(MutableMapping):
+ A case-insensitive `dict`-like object.
diff -Nru python-dugong-3.3+dfsg/debian/patches/series python-dugong-3.3+dfsg/debian/patches/series
--- python-dugong-3.3+dfsg/debian/patches/series 2014-11-15 05:44:21.0 -0800
+++ python-dugong-3.3+dfsg/debian/patches/series 2014-12-03 09:12:46.0 -0800
@@ -1,2 +1,3 @@
fix_test_examples.diff
use-local-intersphinx.patch
+bug_771756.diff
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
severity 771969 important thanks Thanks for the report! I'll set the severity to important for now, because the package still works nicely for many other users. Not sure why it's making so much trouble for you.. but I notice that (like the last bug you found) this seems related to the handling of unreliable network connections. In this case there seems to be a temporary problem with your DNS server which S3QL has trouble coping with. The raw_streamXXX files are from the patch that you applied to the debug the previous issue. I'd recommend to purge and reinstall both the s3ql and python3-dugong packages to make sure that you're in vanilla state again. If the file system still hangs (or the next time it hangs), could you follow the instructions at https://bitbucket.org/nikratio/s3ql/wiki/Providing%20Debugging%20Info to obtain a Python stacktrace, and attach it to this issue? Thanks! -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771969: s3ql: mount.s3ql throws exception and hangs file system
Hi, Is it possible that your DNS server behaves as described in https://bitbucket.org/nikratio/python-dugong/issue/16/? If so, could you test if upgrading to python3-dugong 3.4 from experimental fixes the problem? (In that case there still remains the issue of mount.s3ql hanging instead of terminating cleanly, so the stacktrace would be useful even then). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On 12/01/2014 07:31 AM, Nikolaus Rath wrote: Attached is the object_list.txt file from running fsck using your patch. Seems a little peculiar that the exception occurs at the 10 object mark, though it may simply be chance and mean nothing: ..processed 10 objects so far.. That does not make sense to me. The file that you attached has only 99540 lines. As far as I can tell, there is no way for the above message to be emitted before 10 lines have been written to the file. Could you post the complete output of fsck.s3ql again, just to be sure? It is in fact happening that way, however, since it only updates in increments of 500, if this is a bug, it is effectively an off by one error Well, not really. It just prints the current status *every 500* objects, so it really can't be off by 500. The only explanation that I have is that for some reason Python did not flush the file system buffer cache when it encountered the exception, so we're just seeing part of the while. But that really should happen automatically. But apparently it doesn't always, what we've seen here is probably Python bug 17852 (http://bugs.python.org/issue17852). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On 12/02/2014 02:20 PM, Shannon Dealy wrote:
On Tue, 2 Dec 2014, Shannon Dealy wrote:
[snip]
I performed a capture as requested, ...
Sorry Nikolaus,
I have deleted that file from where I posted it.
I made a mistake, that file was captured with ssl enabled. In fact, it
appears based on a limited sample, that fsck.s3ql fails 100% of the time
when ssl is enabled (35+ runs), and succeeds 100% of the time when ssl
is disabled (6 runs so far). I don't know if this is a generic work
around, or if it just happens to work this way for my particular data set.
Looks like a pattern, thanks a lot for all the tests!
Given the above, there is no way I can provide you with a no-ssl
version of the captured data (since it always succeeds). Could you make
a patch to fsck.s3ql which would provide you with the required data?
Not to fsck.s3ql, but the attached patch should enable traffic dumping
on the lower-level dugong library. It creates files raw_stream_xx.dat
in the current directory. Could you give that a shot and attach both the
results for an ssl and no-ssl run?
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
diff --git a/dugong/__init__.py b/dugong/__init__.py
--- a/dugong/__init__.py
+++ b/dugong/__init__.py
@@ -17,7 +17,9 @@
import ssl
import hashlib
from inspect import getdoc
+from itertools import count
import textwrap
+import os
from base64 import b64encode
from collections import deque
from collections.abc import MutableMapping, Mapping
@@ -424,6 +426,11 @@
self._in_remaining = None
self._pending_requests = deque()
+for i in count():
+if not os.path.exists('raw_stream_%d.dat' % i):
+break
+self.dumpfh = open('raw_stream_%d.dat' % i, 'wb')
+
log.debug('done')
def _co_tunnel(self):
@@ -573,7 +580,7 @@
'''Send *buf* to server'''
log.debug('trying to send %d bytes', len(buf))
-
+
if not isinstance(buf, memoryview):
buf = memoryview(buf)
@@ -608,6 +615,7 @@
continue
log.debug('sent %d bytes', len_)
+self.dumpfh.write(buf[:len_])
buf = buf[len_:]
if len(buf) == 0:
log.debug('done')
@@ -922,6 +930,7 @@
buf2 = self._sock.recv(size - len(buf))
if not buf2:
break
+self.dumpfh.write(buf2)
buf += buf2
else:
buf += rbuf.exhaust()
@@ -1062,6 +1071,7 @@
raise ConnectionClosed('connection closed unexpectedly')
log.debug('got %d bytes', read)
+self.dumpfh.write(buf[pos:pos+read])
self._in_remaining -= read
pos += read
if pos == len_:
@@ -1213,6 +1223,7 @@
assert rbuf.e len(rbuf.d)
raise ConnectionClosed('connection closed unexpectedly')
+self.dumpfh.write(rbuf.d[rbuf.e:rbuf.e+len_])
rbuf.e += len_
log.debug('done (got %d bytes)', len_)
return len_
@@ -1288,6 +1299,7 @@
self._sock.close()
self._sock = None
self._rbuf.clear()
+self.dumpfh.close()
else:
log.debug('already closed')
Bug#771452: Duplicate object check
On 12/02/2014 03:35 PM, Nikolaus Rath wrote: Not to fsck.s3ql, but the attached patch should enable traffic dumping on the lower-level dugong library. It creates files raw_stream_xx.dat in the current directory. Could you give that a shot and attach both the results for an ssl and no-ssl run? Got the dump file via separate mail, thanks! I think I have found the bug. When using SSL, S3QL has to re-establish the connection while retrieving objects. After reconnecting, it starts retrieving from wrong key. The last requests with the first connection are: GET /?prefix=server-externals3ql_data_marker=server-externals3ql_data_188293max-keys=1000 HTTP/1.1 GET /?prefix=server-externals3ql_data_marker=server-externals3ql_data_189193max-keys=1000 HTTP/1.1 GET /?prefix=server-externals3ql_data_marker=server-externals3ql_data_190092max-keys=1000 HTTP/1.1 but then the new connection continues with GET /?prefix=server-externals3ql_data_marker=s3ql_data_190092max-keys=1000 HTTP/1.1 In contrast, when not using SSL the connection does not have to be re-established, so everything works fine. I should be able to fix the bug now. I'm curious why the connection has to be re-established when using SSL though. Would you mind to run fsck.s3ql one more time, this time with --debug, and attach the entries from ~/.s3ql/fsck.log? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
Hi,
Could you try if the attached patch fixes the problem? (You could do
that at the same time as the fsck.s3ql --debug run).
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
diff --git a/src/s3ql/backends/s3c.py b/src/s3ql/backends/s3c.py
--- a/src/s3ql/backends/s3c.py
+++ b/src/s3ql/backends/s3c.py
@@ -209,7 +209,7 @@
log.debug('list(%s, %s): start', prefix, start_after)
keys_remaining = True
-marker = start_after
+marker = self.prefix + start_after
prefix = self.prefix + prefix
ns_p = self.xml_ns_prefix
Bug#771452: Duplicate object check
Now (most likely) fixed in https://bitbucket.org/nikratio/s3ql/commits/8e563c492228a4d0669277d1b45a89955b68 Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
severity 771452 important thanks On 12/02/2014 01:50 PM, Shannon Dealy wrote: On Mon, 1 Dec 2014, Nikolaus Rath wrote: severity -1 normal retitle -1 fsck.s3ql sporadically crashes when checking objects thanks Retitling this bug and lowering severity for now. I don't think that the mount.s3ql crash is related to the fsck.s3ql crashes, or that there is any data corruption. While I understand your assessment, I don't think I would characterize this bug as normal. Based on my understanding, the Debian guidelines would rate this bug at the very least as important, and frankly I would still argue for critical given that it effectively causes serious data loss (one of the possible criteria for critical). My reasoning is that even assuming the file system data has not actually been lost or corrupted (and I believe you are likely correct in this), I ran fsck.s3ql roughly 30 times before getting a successful run. There is nothing to indicate that someone else with similar circumstances would not have to run it 1000 or 100,000 more times in order to recover the file system. For such a case, their data is unavailable to them and effectively 100% lost until they have a fixed version of fsck.s3ql I think the crucial difference is that the data is inaccessible, not lost. It can easily be retrieved by upgrading S3QL, and chances are that enabling/disabling SSL or using a different network connection may also help. A data *loss* means that data is destroyed, not that it's unavailable. Putting it differently, anything that is lost until x is not lost. But there's little point in arguing about severity. I'll set it to important, that's still enough to get an update into jessie. Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771879: unblock: s3ql/2.11.1+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package s3ql. This version fixes bug #771452
(severity important). There are no other changes to the version
currently in testing.
The package is not yet uploaded because I'm waiting for my sponsor.
I'm sending the unblock request now in the hope that this will
ensure that it's in time for the December 5 deadline for important
bugs.
Changelog:
s3ql (2.11.1+dfsg-2) unstable; urgency=medium
* Fixed a problem with fsck.s3ql aborting with an
apsw.ConstraintError or incorrectly considering storage
objects as missing when the connection to remote server is
interrupted. Closes: #771452.
-- Nikolaus Rath nikol...@rath.org Tue, 02 Dec 2014 21:44:27 -0800
Debdiff is attached.
unblock s3ql/2.11.1+dfsg-2
diff -Nru s3ql-2.11.1+dfsg/debian/changelog s3ql-2.11.1+dfsg/debian/changelog
--- s3ql-2.11.1+dfsg/debian/changelog 2014-09-05 13:31:29.0 -0700
+++ s3ql-2.11.1+dfsg/debian/changelog 2014-12-02 21:46:52.0 -0800
@@ -1,3 +1,12 @@
+s3ql (2.11.1+dfsg-2) unstable; urgency=medium
+
+ * Fixed a problem with fsck.s3ql aborting with an
+apsw.ConstraintError or incorrectly considering storage
+objects as missing when the connection to remote server is
+interrupted. Closes: #771452.
+
+ -- Nikolaus Rath nikol...@rath.org Tue, 02 Dec 2014 21:44:27 -0800
+
s3ql (2.11.1+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff
--- s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff 1969-12-31 16:00:00.0 -0800
+++ s3ql-2.11.1+dfsg/debian/patches/bug_771452.diff 2014-12-02 21:49:27.0 -0800
@@ -0,0 +1,28 @@
+Description: Fix bug 771452
+Origin: upstream commit 8e563c49
+Forwarded: not-needed
+Last-Update: 2014-12-02
+Author: Nikolaus Rath nikol...@rath.org
+
+--- a/src/s3ql/backends/s3c.py
b/src/s3ql/backends/s3c.py
+@@ -209,7 +209,7 @@
+ log.debug('list(%s, %s): start', prefix, start_after)
+
+ keys_remaining = True
+-marker = start_after
++marker = self.prefix + start_after
+ prefix = self.prefix + prefix
+ ns_p = self.xml_ns_prefix
+
+--- a/src/s3ql/backends/swift.py
b/src/s3ql/backends/swift.py
+@@ -495,7 +495,7 @@
+ log.debug('list(%s, %s): start', prefix, start_after)
+
+ keys_remaining = True
+-marker = start_after
++marker = self.prefix + start_after
+ prefix = self.prefix + prefix
+
+ while keys_remaining:
diff -Nru s3ql-2.11.1+dfsg/debian/patches/series s3ql-2.11.1+dfsg/debian/patches/series
--- s3ql-2.11.1+dfsg/debian/patches/series 2014-09-04 19:07:59.0 -0700
+++ s3ql-2.11.1+dfsg/debian/patches/series 2014-12-02 21:47:01.0 -0800
@@ -1,3 +1,4 @@
proc_mount.diff
clock-granularity.diff
check_dev_fuse_perms.diff
+bug_771452.diff
Bug#771452: Duplicate object check
On 12/01/2014 02:04 AM, Shannon Dealy wrote: On Sun, 30 Nov 2014, Nikolaus Rath wrote: On 11/30/2014 07:07 PM, Nikolaus Rath wrote: On 11/30/2014 01:07 AM, Shannon Dealy wrote: Attached is the object_list.txt file from running fsck using your patch. Seems a little peculiar that the exception occurs at the 10 object mark, though it may simply be chance and mean nothing: ..processed 10 objects so far.. That does not make sense to me. The file that you attached has only 99540 lines. As far as I can tell, there is no way for the above message to be emitted before 10 lines have been written to the file. Could you post the complete output of fsck.s3ql again, just to be sure? It is in fact happening that way, however, since it only updates in increments of 500, if this is a bug, it is effectively an off by one error. Well, not really. It just prints the current status *every 500* objects, so it really can't be off by 500. The only explanation that I have is that for some reason Python did not flush the file system buffer cache when it encountered the exception, so we're just seeing part of the while. But that really should happen automatically. If it really is failing with this message, please try the attached patch, run fsck.s3ql with --debug-modules s3ql.fsck and attach ~/.s3ql/fsck.log* (depending on the bucket size, there may be several log files). It maxed out your log file limit (see attached .tgz file), but this was interesting as it occurs at the point of the exception: i=10, obj_name=s3ql_data_1, obj_id=1 since the previous object was object_id=190092, following the pattern of object listing, the above obj_id should probably be 190093 not 1. Not necessarily 190093, but probably not 1 (because that should have been the first object, but unfortunately that's missing from the logs). I think at this point I can probably write you a patch to get the file system functional again, but I'd very much like to find out what's happening here. Would you be able to run fsck with --backend-options no-ssl, and capture the traffic using Wireshark? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On 12/01/2014 02:31 PM, Shannon Dealy wrote: On Mon, 1 Dec 2014, Nikolaus Rath wrote: [snip] I think at this point I can probably write you a patch to get the file system functional again, but I'd very much like to find out what's happening here. Would you be able to run fsck with --backend-options no-ssl, and capture the traffic using Wireshark? Hi Nikolaus, I performed several runs of fsck.s3ql while experimenting with wireshark (it has been years since I've used it or tcpdump) to get the settings right. Each time, fsck.s3ql failed in the same manner. Then when I did what was to be the final run/capture, it ran to completion without errors. Given the behavior above, the first thing that leaps to mind is possibly a race condition. I would usually expect more inconsistency (such as failing at different objects each time) if it was simply uninitialized data or corruption, though those may be possibilities too. That's interesting, but it actually fits my hypothesis. fsck.s3ql is single-threaded, so it's not a race condition. However, when retrieving the object list from S3, S3QL has to do several requests because S3 forces to paginize the list to at most 1 entries per request. I suspect there might be a bug in the pagination handling that causes an object to be listed twice. Most likely, this is only triggered when S3 does something uncommon-but-legal in its responses. But the only way to check this is to get a dump of the raw server response. So if you could try this again a few more times (use the --force option to force an fsck), that would be fantastic. I still have the bucket that was copied using the aws command line tools, and am in the process of copying that to a new bucket for testing so we don't lose the corrupt version, but won't get to testing it tonight. I have not tried to use the original file system since fsck.s3ql succeeded and am not entirely sure if it trust it without knowing what was wrong with fsck.s3ql At this point, I am pretty confident that this is a bug related to object listing. Object listing is only used by fsck.s3ql, so I think that using the file system normally (aka with mount.s3ql) should not result in any problems. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
severity -1 normal retitle -1 fsck.s3ql sporadically crashes when checking objects thanks Retitling this bug and lowering severity for now. I don't think that the mount.s3ql crash is related to the fsck.s3ql crashes, or that there is any data corruption. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Copied bucket
On 11/30/2014 12:50 AM, Shannon Dealy wrote: I suspect this is because you copied the objects into a new bucket, but did not include the associated metadata. Which tool did you use to do the copy, and how did you call it? I used the AWS command line tools: aws s3 sync s3://src-bucket s3://dest-bucket It did fail part way through the transfer, so I restarted it with the same command. When you use the S3 Management Console (https://console.aws.amazon.com/s3/home) to look at the s3ql_metadata object in the original bucket and the copy, does it have the same metadata? While the s3ql_metadata file is there, in the new bucket it is missing all of the keys except the Content-Type. Not sure whether this means the fsck without cached data trashed it, or if amazon's sync was trashing the transfered data because I used it incorrectly or it is broken somehow. I think you have to blame the aws tool for this one. If you think fsck.s3ql is at fault, that's easy enough to check: just run the sync command again and see if the metadata is present before running fsck.s3ql. I don't know if that's a bug in aws, or if you're using it incorrectly, but gsutil is able to copy buckets including metadata (in case you want to try that). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On 11/30/2014 01:07 AM, Shannon Dealy wrote: Attached is the object_list.txt file from running fsck using your patch. Seems a little peculiar that the exception occurs at the 10 object mark, though it may simply be chance and mean nothing: ..processed 10 objects so far.. That does not make sense to me. The file that you attached has only 99540 lines. As far as I can tell, there is no way for the above message to be emitted before 10 lines have been written to the file. Could you post the complete output of fsck.s3ql again, just to be sure? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Copied bucket
On 11/30/2014 12:03 PM, Shannon Dealy wrote: Poking around, it appears that the metadata was lost only on the s3ql_metadata files, so I deleted them and ran the aws s3 sync command again. The new files again were missing the metadata, so I just copied the 13 s3ql_metadata files using the aws console, and this time the metadata was preserved. I didn't see anything special about these files with regard to permissions or other information, is there anything special about how these files are created/stored on S3? No. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: Duplicate object check
On 11/30/2014 07:07 PM, Nikolaus Rath wrote:
On 11/30/2014 01:07 AM, Shannon Dealy wrote:
Attached is the object_list.txt file from running fsck using your patch.
Seems a little peculiar that the exception occurs at the 10 object
mark, though it may simply be chance and mean nothing:
..processed 10 objects so far..
That does not make sense to me. The file that you attached has only
99540 lines.
As far as I can tell, there is no way for the above message to be
emitted before 10 lines have been written to the file.
Could you post the complete output of fsck.s3ql again, just to be sure?
If it really is failing with this message, please try the attached
patch, run fsck.s3ql with --debug-modules s3ql.fsck and attach
~/.s3ql/fsck.log* (depending on the bucket size, there may be several
log files).
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
diff --git a/src/s3ql/fsck.py b/src/s3ql/fsck.py
--- a/src/s3ql/fsck.py
+++ b/src/s3ql/fsck.py
@@ -845,6 +845,7 @@
log.warning(Ignoring unexpected object %r, obj_name)
continue
+log.debug('i=%d, obj_name=%s, obj_id=%d', i, obj_name, obj_id)
self.conn.execute('INSERT INTO obj_ids VALUES(?)', (obj_id,))
for (obj_id,) in self.conn.query('SELECT id FROM obj_ids '
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
On 11/29/2014 09:49 AM, Shannon Dealy wrote: Package: s3ql Version: 2.11.1+dfsg-1 Severity: critical Justification: causes serious data loss Dear Maintainer, While running rsync to backup data to an s3ql file system mounted from Amazon's S3 services, the internet connection failed, resulting in the following error(s) from rsync: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32) rsync: write failed on file name removed: Software caused connection abort (103) rsync error: error in file IO (code 11) at receiver.c(322) [receiver=3.0.9] rsync: connection unexpectedly closed (17298 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9] I attempted to unmount the file system with the following result (twice): # umount.s3ql /media/server-external File system appears to have crashed. Thanks for the report! Could you please include the contents of your ~/.s3ql/mount.log file? As things currently stand, unless I have overlooked or misunderstood something (which I consider entirely possible), this network connection failure has resulted in 100% data loss unless fsck can be fixed in a manner which will allow it to complete correctly and recover the file system data. Chances are good that this can be done, so don't give up hope yet. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
On 11/29/2014 01:36 PM, Shannon Dealy wrote: On Sat, 29 Nov 2014, Nikolaus Rath wrote: On 11/29/2014 09:49 AM, Shannon Dealy wrote: Package: s3ql Version: 2.11.1+dfsg-1 Severity: critical Justification: causes serious data loss Dear Maintainer, While running rsync to backup data to an s3ql file system mounted from Amazon's S3 services, the internet connection failed, resulting in the following [snip] Chances are good that this can be done, so don't give up hope yet. Best, -Nikolaus Attached are both the mount and fsck log files, stripped of data from other (irrelevent) sessions and with slight mods to remove references to my S3 file system info (bucket/prefix). I have left the original bucket and local cache unmodified except for whatever changes occured during my fsck attempt in case they can be of use in debugging this. Great, thanks! It seems you've actually found three issues at once: 1. mount.s3ql not coping well with a failed internet connection (a no route to host failure, to be precise, it copes quite well with other failures) 2. fsck.s3ql not being able to fix the local database 3. A bug somewhere that prevents you from fsck'ing a copied bucket. I'll look into this ASAP. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
On 11/29/2014 03:54 PM, Nikolaus Rath wrote: 1. mount.s3ql not coping well with a failed internet connection (a no route to host failure, to be precise, it copes quite well with other failures) This one is actually a bug in python-dugong. I have just fixed this in https://bitbucket.org/nikratio/python-dugong/commits/36dc1863633b6fe38a02e5ba07dd3b0cf5deeb0f. The fixed version is unlikely to make it into jessie, but it should be possible to get a fixed fsck.s3ql into jessie that can clean up the resulting mess. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771452: s3ql: fsck.s3ql on crashed file system results in uncaught exception
On 11/29/2014 03:54 PM, Nikolaus Rath wrote:
2. fsck.s3ql not being able to fix the local database
This one is more interesting. The traceback looks as if the backend (aka
S3) reports two objects with the same name (which I think should be
impossible). Since S3QL is using the object names as primary keys in a
table, this does not end well.
Could you apply the attached patch to /usr/lib/s3ql/s3ql/fsck.py and
check the original file system again (i.e., not the copy)?
It should crash at the same point as before, but create a file
object_list.txt in the current directory. Please attach that file to
this bug.
Thanks!
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
diff --git a/src/s3ql/fsck.py b/src/s3ql/fsck.py
--- a/src/s3ql/fsck.py
+++ b/src/s3ql/fsck.py
@@ -829,6 +829,9 @@
lof_id = self.conn.get_val(SELECT inode FROM contents_v
WHERE name=? AND parent_inode=?, (blost+found, ROOT_INODE))
+# Debugging
+debug_fh = open('object_list.txt', 'w')
+
# We use this table to keep track of the objects that we have seen
self.conn.execute(CREATE TEMP TABLE obj_ids (id INTEGER PRIMARY KEY))
try:
@@ -838,6 +841,8 @@
sys.stdout.write('\r..processed %d objects so far..' % i)
sys.stdout.flush()
+print(obj_name, file=debug_fh)
+
# We only bother with data objects
try:
obj_id = int(obj_name[10:])
Bug#771491: Resolved
This is a consequence of a missing swap partition (bug #771492). After fixing swap, hibernation works. Wishlist: indicate the problem (missing swap) in the journalctl or systemctl output. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771492: Resolved
Removing the swap keyword from /etc/crypttab makes things work. Technically speaking, this keyword should not be there because I am using the swap partition for hibernation (so mkswap should not be run). It seems that sysvinit silently skipped the mkswap call, while systemd now errors out. I think systemd's behavior is preferable, but it's unfortunate that things break during the upgrade. Would it be possible to scan /etc/crypttab for such problems (like it's planned for /etc/inittab)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771364: /boot/vmlinuz-3.16.0-4-amd64: Resume from hibernate ends with reboot ~20% of the time
Package: src:linux Version: 3.16.7-2 Severity: normal File: /boot/vmlinuz-3.16.0-4-amd64 About 20% of the time that I resume my system from hibernation, it reboots during the resume. After the reboot, the system boots normally (i.e., no resume). For debugging, I have booted with console=ttyS0,115200n8 no_console_suspend and without quiet. I have attached the output for a successful resume. It ends with: [ 30.448711] PM: Read 3382972 kbytes in 10.48 seconds (322.80 MB/s)^M [ 30.456989] nouveau [ DRM] suspending display...^M [ 30.462074] nouveau [ DRM] unpinning framebuffer(s)...^M [ 30.467721] nouveau [ DRM] evicting buffers...^M [ 30.473401] nouveau [ DRM] waiting for kernel channels to go idle...^M [ 30.480214] nouveau [ DRM] suspending client object trees...^M [ 30.492881] nouveau [ DRM] suspending kernel object tree...^M [ 31.834571] PM: quiesce of devices complete after 1376.038 msecs^M [ 31.840934] PM: late quiesce of devices complete after 0.326 msecs^M [ 31.847957] PM: noirq quiesce of devices complete after 0.837 msecs^M [ 31.854229] Disabling non-boot CPUs ...^M [ 31.882768] intel_pstate CPU 1 exiting^M [ 32.018972] smpboot: CPU 1 is now offline^M [ 32.059024] intel_pstate CPU 2 exiting^M [ 32.203233] smpboot: CPU 2 is now offline^M [ 32.235285] intel_pstate CPU 3 exiting^M [ 32.379492] smpboot: CPU 3 is now offline^M [ 32.411547] intel_pstate CPU 4 exiting^M [ 32.499750] usb 2-1-port1: cannot reset (err = -113)^M [ 32.504726] usb 2-1-port1: cannot reset (err = -113)^M [ 32.509699] usb 2-1-port1: cannot reset (err = -113)^M [ 32.514672] usb 2-1-port1: cannot reset (err = -113)^M [ 32.519647] usb 2-1-port1: cannot reset (err = -113)^M [ 32.524613] usb 2-1-port1: Cannot enable. Maybe the USB cable is bad?^M [ 32.531066] usb 2-1-port1: cannot disable (err = -113)^M [ 32.536208] usb 2-1-port1: cannot reset (err = -113)^M [ 32.663915] intel_pstate CPU 5 exiting^M [ 32.784085] smpboot: CPU 5 is now offline^M [ 32.864205] intel_pstate CPU 6 exiting^M [ 32.901389] smpboot: CPU 6 is now offline^M [ 32.948328] intel_pstate CPU 7 exiting^M [ 32.965482] smpboot: CPU 7 is now offline^M [16178.661147] Enabling non-boot CPUs ...^M [16178.664970] x86: Booting SMP configuration:^M In contrast to that, the last messages that I get when the system reboots are: [ 23.104427] PM: quiesce of devices complete after 1487.470 msecs [ 23.110632] PM: late quiesce of devices complete after 0.184 msecs [ 23.117692] PM: noirq quiesce of devices complete after 0.869 msecs [ 23.123964] Disabling non-boot CPUs ... [ 23.160413] intel_pstate CPU 1 exiting [ 23.296607] smpboot: CPU 1 is now offline [ 23.340676] intel_pstate CPU 2 exiting [ 23.476872] smpboot: CPU 2 is now offline [ 23.516937] intel_pstate CPU 3 exiting [ 23.64] smpboot: CPU 3 is now offline [ 23.677170] intel_pstate CPU 4 exiting [ 23.813368] smpboot: CPU 4 is now offline [ 23.869452] intel_pstate CPU 5 exiting [ 24.005649] smpboot: CPU 5 is now offline [ 24.025679] intel_pstate CPU 6 exiting [ 24.061741] NOHZ: local_softirq_pending 10 [ 24.169889] smpboot: CPU 6 is now offline [ 24.205945] intel_pstate CPU 7 exiting [ 24.223097] smpboot: CPU 7 is now offline I'm working on getting the full log for a broking resume too, but maybe the above is already enough to tell what's going on? -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg0-debian ro quiet splash init=/bin/systemd console=ttyS0,115200n8 no_console_suspend ** Not tainted ** Kernel log: [ 71.279914] Btrfs loaded [ 71.612560] BTRFS: device label debian devid 1 transid 188240 /dev/mapper/vg0-debian [ 71.614252] PM: Starting manual resume from disk [ 71.614256] PM: Hibernation image partition 254:5 present [ 71.614257] PM: Looking for hibernation image. [ 71.614740] PM: Image not found (code -22) [ 71.614743] PM: Hibernation image not present or could not be loaded. [ 71.621129] BTRFS info (device dm-0): disk space caching is enabled [ 75.348213] lp: driver loaded but no devices found [ 75.375569] ppdev: user-space parallel port driver [ 75.448405] fuse init (API version 7.23) [ 75.480857] loop: module loaded [ 75.668043] systemd-udevd[388]: starting version 215 [ 75.987394] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 [ 77.223671] BTRFS info (device dm-0): disk space caching is enabled [ 77.754846] ACPI Warning: SystemIO range 0x0428-0x042f conflicts with OpRegion 0x0400-0x047f (\PMIO) (20140424/utaddress-258) [ 77.754851] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 77.754854] ACPI Warning: SystemIO range
Bug#771364: Full logs
As promised, here are the full logs for a resume attempt ending with reboot. microcom -p /dev/ttyUSB0 connected to /dev/ttyUSB0 Escape character: Ctrl-\ Type the escape character followed by c to get to the menu or q to quit [0.00] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg0-debian ro splash init=/bin/systemd console=ttyS0,115200n8 no_console_suspend [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00091bff] usable [0.00] BIOS-e820: [mem 0x00091c00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xdeb8] usable [0.00] BIOS-e820: [mem 0xdeb9-0xdf13] reserved [0.00] BIOS-e820: [mem 0xdf14-0xdf384fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdf385000-0xdf392fff] ACPI data [0.00] BIOS-e820: [mem 0xdf393000-0xdf3b] ACPI NVS [0.00] BIOS-e820: [mem 0xdf3c-0xdf3c4fff] ACPI data [0.00] BIOS-e820: [mem 0xdf3c5000-0xdf407fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdf408000-0xdf7f] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x21f000 max_arch_pfn = 0x4 [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xdf800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fcd90-0x000fcd9f] mapped at [880fcd90] [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] init_memory_mapping: [mem 0x21ee0-0x21eff] [0.00] init_memory_mapping: [mem 0x21c00-0x21edf] [0.00] init_memory_mapping: [mem 0x2-0x21bff] [0.00] init_memory_mapping: [mem 0x0010-0xdeb8] [0.00] init_memory_mapping: [mem 0xdf408000-0xdf7f] [0.00] init_memory_mapping: [mem 0x1-0x1] [0.00] RAMDISK: [mem 0x35a2a000-0x36d0cfff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F0450 24 (v02 ALASKA) [0.00] ACPI: XSDT 0xDF385070 5C (v01 ALASKA A M I 01072009 AMI 00010013) [0.00] ACPI: FACP 0xDF390C00 F4 (v04 ALASKA A M I 01072009 AMI 00010013) [0.00] ACPI: DSDT 0xDF385168 00BA92 (v02 ALASKA A M I 0015 INTL 20051117) [0.00] ACPI: FACS 0xDF3BEF80 40 [0.00] ACPI: APIC 0xDF390CF8 92 (v03 ALASKA A M I 01072009 AMI 00010013) [0.00] ACPI: MCFG 0xDF390D90 3C (v01 ALASKA A M I 01072009 MSFT 0097) [0.00] ACPI: HPET 0xDF390DD0 38 (v01 ALASKA A M I 01072009 AMI. 0005) [0.00] ACPI: SSDT 0xDF390E08 00036D (v01 SataRe SataTabl 1000 INTL 20091112) [0.00] ACPI: SSDT 0xDF391178 0009AA (v01 PmRef Cpu0Ist 3000 INTL 20051117) [0.00] ACPI: SSDT 0xDF391B28 000A92 (v01 PmRef CpuPm 3000 INTL 20051117) [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x00021eff] [0.00] Initmem setup node 0 [mem 0x-0x21eff] [0.00] NODE_DATA [mem 0x21eff4000-0x21eff8fff] [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x21eff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x00090fff] [0.00] node 0: [mem 0x0010-0xdeb8] [0.00] node 0: [mem
Bug#769607: systemd does not show shutdown or reboot messages with systemd.show_status=true
On Sat, 15 Nov 2014 00:17:59 +0100 Szymon Weihs szyn...@gmail.com wrote: When I'm doing reboot or shutdown from graphical environment (systemctl reboot/poweroff), my screen turns off immediately so I can't see any messages provided with option systemd.show_status=true. If I shutdown my computer from console (for example tty1) everything works as expected - I can see all messages included the last Reached target shutdown and then the screen turns off along with the computer. As a workaround, does it help if you add ExecStop=/bin/chvt 1 to the [Service] section of /etc/systemd/system/display-manager.service? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769369: Workaround found
Hello, I have found that adding ExecStop=/bin/chvt 1 ExecStop=/sbin/start-stop-daemon --stop --quiet --pidfile /var/run/lightdm.pid --name lightdm --retry 5 to the [Service] section in /etc/systemd/system/lightdm.service fixes the problem. Shutdown and reboot work properly. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769607: update
I just checked, and the system that is not affected by this issue is using the radeon driver. Might this be a problem with both the i915 and the nouveau driver? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769369: More info
I have a second system that is not affected by this, but it uses the radeon driver. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769607: Confirmed here
I'm having the same problem, see #769369. Unfortunately I haven't been able to tie this to any specific package or hardware. I see it happening on some systems, but not on others. My first guess was the graphics driver, but it happens with both intel (i915) and nvidia (nouveau) cards. Which card and module are you using? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769607: Confirmed here
On 11/16/2014 10:05 AM, intrigeri wrote: Control: tag -1 + moreinfo Hi Szymon and Nikolaus, Nikolaus Rath wrote (16 Nov 2014 16:53:49 GMT) : I'm having the same problem, see #769369. Unfortunately I haven't been able to tie this to any specific package or hardware. I see it happening on some systems, but not on others. My first guess was the graphics driver, but it happens with both intel (i915) and nvidia (nouveau) cards. Which card and module are you using? Do you have plymouth installed? i.e. what's the output of dpkg -l plymouth* In my case, plymouth is installed on both the system that suffers from the problem and one the system that works fine. Plymouth theme is details in both cases. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769466: /boot/vmlinuz-3.16.0-4-amd64: Kernel Oops when specifying console=ttyS0
Package: src:linux Version: 3.16.7-2 Severity: normal File: /boot/vmlinuz-3.16.0-4-amd64 Hello, When adding console=ttyS0,115200n8 console=tty0 no_console_suspend to the kernel command line, I'm getting the following kernel Oops during boot (full quote in kernel.log below): [...] [ 13.687971] :07:01.0: ttyS0 at I/O 0xc050 (irq = 19, base_baud = 115200) is a 16550A [ 13.687980] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 13.688130] BUG: unable to handle kernel paging request at 819419bf [ 13.688299] IP: [819419bf] serial8250_console_setup+0x0/0xaa [ 13.688604] PGD 1816067 PUD 1817063 PMD 215f93063 PTE 81941163 [ 13.688911] Oops: 0011 [#1] SMP [...] Please let me know if I can do something to debug this further. -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg0-debian ro quiet splash init=/bin/systemd console=ttyS0,115200n8 console=tty0 no_console_suspend ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [ 20.903746] systemd-journald[371]: Received request to flush runtime journal from PID 1 [ 22.175694] systemd-journald[371]: File /var/log/journal/b865c77cc176b5ef3b69390a000d/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 24.031382] Bridge firewalling registered [ 24.035136] device eth0 entered promiscuous mode [ 24.191505] e1000e :00:19.0: irq 41 for MSI/MSI-X [ 24.294929] e1000e :00:19.0: irq 41 for MSI/MSI-X [ 24.295393] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 24.302646] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready [ 25.818352] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 25.818757] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO [ 25.819188] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 25.819615] br0: port 1(eth0) entered forwarding state [ 25.821684] br0: port 1(eth0) entered forwarding state [ 25.823769] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready [ 40.871234] br0: port 1(eth0) entered forwarding state [ 46.534455] tun: Universal TUN/TAP device driver, 1.6 [ 46.534460] tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com [ 265.780024] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.784034] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.784416] hid-generic 0003:05F3:0007.0005: can't reset device, :00:1d.0-1.4.2.1.2/input1, status -71 [ 265.788029] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.788398] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.792404] hid-generic 0003:05F3:0007.0004: can't reset device, :00:1d.0-1.4.2.1.2/input0, status -71 [ 265.792653] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.796673] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.796907] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.800917] hid-generic 0003:05F3:0007.0005: can't reset device, :00:1d.0-1.4.2.1.2/input1, status -71 [ 265.801171] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.805190] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.805423] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.809432] hid-generic 0003:05F3:0007.0004: can't reset device, :00:1d.0-1.4.2.1.2/input0, status -71 [ 265.809676] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.813699] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.813931] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.817944] hid-generic 0003:05F3:0007.0005: can't reset device, :00:1d.0-1.4.2.1.2/input1, status -71 [ 265.818188] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.822211] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.822448] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.826455] hid-generic 0003:05F3:0007.0004: can't reset device, :00:1d.0-1.4.2.1.2/input0, status -71 [ 265.826700] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.830749] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.830960] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.834980] hid-generic 0003:05F3:0007.0005: can't reset device, :00:1d.0-1.4.2.1.2/input1, status -71 [ 265.835213] usb 6-1.4.2: clear tt 2 (0080) error -71 [ 265.839261] hid-generic 0003:1A7C:0068.0003: can't reset device, :00:1d.0-1.4.2.2/input0, status -71 [ 265.839471] usb 6-1.4.2: clear tt 1 (0090) error -71 [ 265.843481] hid-generic 0003:05F3:0007.0004: can't reset device, :00:1d.0-1.4.2.1.2/input0, status -71 [ 265.843726] usb 6-1.4.2: clear tt 2
Bug#769466: /boot/vmlinuz-3.16.0-4-amd64: Kernel Oops when specifying console=ttyS0
Control: tag -1 -moreinfo On 11/13/2014 01:45 PM, Ben Hutchings wrote: On Thu, 2014-11-13 at 12:53 -0800, Nikolaus Rath wrote: Package: src:linux Version: 3.16.7-2 Severity: normal File: /boot/vmlinuz-3.16.0-4-amd64 Hello, When adding console=ttyS0,115200n8 console=tty0 no_console_suspend to the kernel command line, I'm getting the following kernel Oops during boot (full quote in kernel.log below): [...] [ 13.687971] :07:01.0: ttyS0 at I/O 0xc050 (irq = 19, base_baud = 115200) is a 16550A [ 13.687980] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 13.688130] BUG: unable to handle kernel paging request at 819419bf [ 13.688299] IP: [819419bf] serial8250_console_setup+0x0/0xaa [ 13.688604] PGD 1816067 PUD 1817063 PMD 215f93063 PTE 81941163 [ 13.688911] Oops: 0011 [#1] SMP [...] Please let me know if I can do something to debug this further. [...] The log didn't include the full oops message; please can you send that as I don't understand why anything would call this function at this point. (It is only meant to be called during kernel initialisation, before starting the init program. At this point the code has been freed, hence the page fault.) Full log is attached. Sorry, I did not realize that the automatically included log was truncated. -Nikolaus [0.00] CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 root=/dev/mapper/vg0-debian ro quiet splash init=/bin/systemd console=ttyS0,115200n8 console=tty0 no_console_suspend [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00091bff] usable [0.00] BIOS-e820: [mem 0x00091c00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xdeb8] usable [0.00] BIOS-e820: [mem 0xdeb9-0xdf13] reserved [0.00] BIOS-e820: [mem 0xdf14-0xdf384fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdf385000-0xdf392fff] ACPI data [0.00] BIOS-e820: [mem 0xdf393000-0xdf3b] ACPI NVS [0.00] BIOS-e820: [mem 0xdf3c-0xdf3c4fff] ACPI data [0.00] BIOS-e820: [mem 0xdf3c5000-0xdf407fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdf408000-0xdf7f] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: System manufacturer System Product Name/P8Z68-V GEN3, BIOS 3603 11/09/2012 [0.00] e820: update [mem 0x-0x0fff] usable == reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x21f000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-DBFFF write-protect [0.00] DC000-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask E write-back [0.00] 1 base 2 mask FF000 write-back [0.00] 2 base 21000 mask FF800 write-back [0.00] 3 base 21800 mask FFC00 write-back [0.00] 4 base 21C00 mask FFE00 write-back [0.00] 5 base 21E00 mask FFF00 write-back [0.00] 6 base 0E000 mask FE000 uncachable [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xe000-0x] usable == reserved [0.00] e820: last_pfn = 0xdf800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fcd90-0x000fcd9f] mapped
Bug#769369: systemd: Can't restart or poweroff when X11 is active
On a whim, I also tried blacklisting the nouveau module and using the integrated graphics with the i915 module instead. It did not make a difference. -Nikolaus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769466: /boot/vmlinuz-3.16.0-4-amd64: Kernel Oops when specifying console=ttyS0
On November 13, 2014 5:03:56 PM PST, Ben Hutchings b...@decadent.org.uk wrote: On 11/13/2014 01:45 PM, Ben Hutchings wrote: On Thu, 2014-11-13 at 12:53 -0800, Nikolaus Rath wrote: Package: src:linux Version: 3.16.7-2 Severity: normal File: /boot/vmlinuz-3.16.0-4-amd64 Hello, When adding console=ttyS0,115200n8 console=tty0 no_console_suspend to the kernel command line, I'm getting the following kernel Oops during boot (full quote in kernel.log below): [...] [ 13.687971] :07:01.0: ttyS0 at I/O 0xc050 (irq = 19, base_baud = 115200) is a 16550A [ 13.687980] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 13.688130] BUG: unable to handle kernel paging request at 819419bf [ 13.688299] IP: [819419bf] serial8250_console_setup+0x0/0xaa [ 13.688604] PGD 1816067 PUD 1817063 PMD 215f93063 PTE 81941163 [ 13.688911] Oops: 0011 [#1] SMP [...] Please let me know if I can do something to debug this further. [...] The log didn't include the full oops message; please can you send that as I don't understand why anything would call this function at this point. (It is only meant to be called during kernel initialisation, before starting the init program. At this point the code has been freed, hence the page fault.) Full log is attached. Sorry, I did not realize that the automatically included log was truncated. This bug seems to be specific to parport_serial. Only built-in drivers can be console drivers, but parport_serial is built as a module. However, because it works on top of with 8250_pci, which *is* built-in, the kernel tries to use it as a console driver anyway, and this leads to the crash. We should fix the crash, but you still won't be able to use ports on the combined parallel/serial card for a console. Duh. Not at all, or will it work if I build my own kernel with parport_serial built-in? Do I understand correctly that a pci card with only serial ports would work without changes? Best, Nikolaus -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769250: python-dugong: FTBFS in jessie/i386: dh_auto_test: pybuild --test -i python{version} -p 3.4 --dir . returned exit code 13
On 11/12/2014 10:42 AM, Andrey Rahmatullin wrote: On Wed, Nov 12, 2014 at 11:22:55AM +0100, Lucas Nussbaum wrote: === FAILURES === _ test_httpcat _ Traceback (most recent call last): File /«BUILDDIR»/python-dugong-3.3+dfsg/test/test_examples.py, line 53, in test_httpcat subprocess.check_call(cmdline, stdout=devnull) File /usr/lib/python3.4/subprocess.py, line 561, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/bin/python3.4', '/«BUILDDIR»/python-dugong-3.3+dfsg/test/../examples/httpcat.py', 'http://docs.oracle.com/javaee/7/firstcup/doc/creating-example.htm']' returned non-zero exit status 1 - Captured stderr call - 301 Moved Permanently If it accesses the network it's wrong anyway. It tries to access the network, and if it fails, the test is skipped. In this case, it seems that the first attempt to connect succeeded with status 200, so the test was run. Maybe urllib.request implicitly follows the 301, I'll look into that. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769369: systemd: Can't restart or poweroff when X11 is active
More information: * reboot -f and poweroff -f work fine. * if I start a debug-shell on a serial port, at some point the shell seems to freeze as well. * if I boot with sysvinit (installing sysvinit-core instead of systemd-sysv), things work fine: - The system reboots even if an X11 console is active - During the shutdown, I can switch between text consoles and see log messages It seems that there is some problem with the way that X11 is terminated when using systemd. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768225: plymouth: Plymouth makes console inaccessible on shutdown
Package: plymouth Version: 0.9.0-7 Severity: normal When *not* passing splash in the kernel command line, I can execute systemctl reboot (or systemctl shutdown) and access the text console during the shutdown process. In particular, I can use Ctrl+Alt+Fx to interact with the systemd debug shell on tty9, or see system log messages on tty9. However, when passing splash to the kernel, this is no longer possible. The system does not react to Ctrl+Alt+Fx, and the monitor goes into standby. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages plymouth depends on: ii initramfs-tools0.116 ii libc6 2.19-11 ii libdrm22.4.58-2 ii libpng12-0 1.2.50-2 ii libudev1 215-5+b1 ii multiarch-support 2.19-11 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 7.0.3 ii plymouth-themes 0.9.0-7 -- Configuration Files: /etc/plymouth/plymouthd.conf changed: [Daemon] Theme=solar -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764557: extra info
Update: when running sufficiently long, journalctl eventually prints something, but it is *very* slow. The strace output is: mmap(NULL, 4198400, PROT_READ, MAP_SHARED, 6, 0x528000) = 0x7f46ace1a000 munmap(0x7f46ab617000, 8388608) = 0 mmap(NULL, 4198400, PROT_READ, MAP_SHARED, 7, 0x84d000) = 0x7f46aba16000 munmap(0x7f46abe17000, 8388608) = 0 mmap(NULL, 8388608, PROT_READ, MAP_SHARED, 8, 0x43e000) = 0x7f46ac058000 munmap(0x7f46ac858000, 4202496) = 0 mmap(NULL, 5251072, PROT_READ, MAP_SHARED, 18, 0x59d000) = 0x7f46ac918000 munmap(0x7f46ad21b000, 8388608) = 0 with several seconds delay in between. Additionally, it seems that my journal grows without bounds. Currently, it is at 820 MB. The first recorded journal entry claims: Apr 19 13:16:41 vostro systemd-journal[488]: Allowing runtime journal files to grow to 159.4M. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764557: more info
retitle 764557 Persistent journal gets corrupted thanks Alright, the journal is not truly growing without bounds. Further below, I found: Permanent journal is using 819.7M (max allowed 3.8G, trying to leave 4.0G free of 6.6G available → current limit 2.6G). So this is probably not the issue. I then tried running journalctl --verify and got several errors: $ journalctl --verify journalctl-verify.log # grep -v PASS journalctl-verify.log Invalid tail monotonic timestamp File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@a26c2d4e0a8e4ed49fb0bad469dee6c6-0611-0004ffc56e15ab8c.journal:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@a26c2d4e0a8e4ed49fb0bad469dee6c6-0611-0004ffc56e15ab8c.journal (Bad message) Invalid tail monotonic timestamp File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-00015774-0004fefdbd6fe9c7.journal:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-00015774-0004fefdbd6fe9c7.journal (Bad message) Invalid data object at hash entry 3944 of 233016 File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@0005065350521a47-17e420d2d51ab126.journal~:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/user-1000@0005065350521a47-17e420d2d51ab126.journal~ (Bad message) Data object references invalid entry at 5182040 File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050713408c0d34-e40e6aa5c35eb139.journal~ (Bad message) Data number mismatch File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/system@000507165d32850c-5b4cd09ceb6b2ea6.journal~:00 (of 16777216 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/system@000507165d32850c-5b4cd09ceb6b2ea6.journal~ (Bad message) Invalid tail monotonic timestamp File corruption detected at /var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-000263f0-000504a444037da7.journal:00 (of 8388608 bytes, 0%). FAIL: /var/log/journal/b865c77cc176b5ef3b69390a000d/user-65534@763da377eefc4369ad61af34c4a5a1c6-000263f0-000504a444037da7.journal (Bad message) /var/log is btrfs. Not sure who's the culprit here. On the plus side, after running the journalctl commands from my first mail now all work. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766297: [Pkg-openssl-devel] Bug#766297: openssl s_client no longer recognizes -ssl3 option
On 10/22/2014 12:15 AM, Kurt Roeckx wrote: On Tue, Oct 21, 2014 at 06:33:50PM -0700, Nikolaus Rath wrote: Package: openssl Version: 1.0.1j-1 Severity: important After my last testing upgrade, openssl s_client has trouble accepting the -ssl3 and -ssl2 options. This prevents e.g. Gnus from using SSL to connect to mailservers. It shouldn't be using the -ssl3 option. The -ssl2 option has been gone for a while. But SSL v3.0 is also insecure and you should stop using it. I also think that it shouldn't be using s_client for anything. s_client is a debug tool, and will not do what you expect. I don't think if matters if -ssl3 (or -ssl2) is insecure or not. Either it should be removed completely (i.e., also from the --help output), or it should work. Having it listed in --help but then not working does not make sense, no matter how secure or insecure. Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766297: openssl s_client no longer recognizes -ssl3 option
Package: openssl Version: 1.0.1j-1 Severity: important After my last testing upgrade, openssl s_client has trouble accepting the -ssl3 and -ssl2 options. This prevents e.g. Gnus from using SSL to connect to mailservers. For example: $ openssl s_client -ssl3 -quiet -connect ebox.rath.org:143 unknown option -ssl3 usage: s_client args -host host - use -connect instead -port port - use -connect instead -connect host:port - who to connect to (default is localhost:4433) -verify arg - turn on peer certificate verification [...] -srp_strength int - minimal mength in bits for N (default 1024). -ssl2 - just use SSLv2 -ssl3 - just use SSLv3 -tls1_2 - just use TLSv1.2 -tls1_1 - just use TLSv1.1 Note that the option is even included in the help output. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openssl depends on: ii libc62.19-11 ii libssl1.0.0 1.0.1j-1 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20140927 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766297: Acknowledgement (openssl s_client no longer recognizes -ssl3 option)
Downgrading to 1.0.1i-2 fixes the problem. -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764555: systemd: cryptsetup password overwritten/hidden by status messages
Package: systemd Version: 215-5+b1 Severity: normal Hello, I'm running Debian testing. After the last dist-upgrade, systemd has started showing status messages during boot (sort of like sysvinit used to do). This is certainly much prettier and more informative than the blank screen that I had before, but it has the unfortunate side-effect of interfering with the cryptsetup password prompt. Sometimes the prompt is several lines before the cursor with other messsages in between, and sometimes it's actually overwritten completely. It'd be nice if status output would be suppressed/delayed while a password prompty is active. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.4 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.20.1-5.11 ii libc6 2.19-11 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-1 ii libgcrypt20 1.6.2-3 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5+b1 ii sysv-rc 2.88dsf-53.4 ii udev215-5+b1 ii util-linux 2.20.1-5.11 Versions of packages systemd recommends: ii dbus1.8.8-1+b1 ii libpam-systemd 215-5+b1 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764555: systemd: cryptsetup password overwritten/hidden by status messages
On 10/08/2014 05:47 PM, Michael Biebl wrote: Am 09.10.2014 um 02:43 schrieb Nikolaus Rath: Package: systemd Version: 215-5+b1 Severity: normal Hello, I'm running Debian testing. After the last dist-upgrade, systemd has started showing status messages during boot (sort of like sysvinit used to do). This is certainly much prettier and more informative than the blank screen that I had before, but it has the unfortunate side-effect of interfering with the cryptsetup password prompt. Sometimes the prompt is several lines before the cursor with other messsages in between, and sometimes it's actually overwritten completely. It'd be nice if status output would be suppressed/delayed while a password prompty is active. You'll need something like plymouth to multiplex the input/output. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ In that case it'd be great if the systemd or the cryptsetup package could recommend or suggest the appropriate package (plymouth?). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: OpenPGP digital signature
Bug#764555: systemd: cryptsetup password overwritten/hidden by status messages
On 10/08/2014 06:17 PM, Michael Biebl wrote: Am 09.10.2014 um 02:51 schrieb Nikolaus Rath: On 10/08/2014 05:47 PM, Michael Biebl wrote: Am 09.10.2014 um 02:43 schrieb Nikolaus Rath: Package: systemd Version: 215-5+b1 Severity: normal Hello, I'm running Debian testing. After the last dist-upgrade, systemd has started showing status messages during boot (sort of like sysvinit used to do). This is certainly much prettier and more informative than the blank screen that I had before, but it has the unfortunate side-effect of interfering with the cryptsetup password prompt. Sometimes the prompt is several lines before the cursor with other messsages in between, and sometimes it's actually overwritten completely. It'd be nice if status output would be suppressed/delayed while a password prompty is active. You'll need something like plymouth to multiplex the input/output. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ In that case it'd be great if the systemd or the cryptsetup package could recommend or suggest the appropriate package (plymouth?). Could you verify that plymouth solves your problem? Yes it did. Thank you! -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: OpenPGP digital signature
Bug#764557: systemd: journalctl just hangs
Package: systemd
Version: 215-5+b1
Severity: normal
Hello,
On this system, journalctl simply hangs. I tried running journalctl,
journalctl -b, and journalctl --list-boots, but nothing seems to do
anything:
# strace -o log journalctl --list-boots
^C
# tail log
open(/var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050015e4e89ee2-7772b44515f976b3.journal~,
O_RDONLY|O_CLOEXEC) = 24
fstat(24, {st_mode=S_IFREG|0755, st_size=8388608, ...}) = 0
mmap(NULL, 4096, PROT_READ, MAP_SHARED, 24, 0) = 0x7f36cf8fa000
mmap(NULL, 8388608, PROT_READ, MAP_SHARED, 24, 0) = 0x7f36c4092000
fstatfs(24, {f_type=0x9123683e, f_bsize=4096, f_blocks=10125312,
f_bfree=4197815, f_bavail=2391939, f_files=0, f_ffree=0, f_fsid={2146103056,
892494683}, f_namelen=255, f_frsize=4096}) = 0
open(/var/log/journal/b865c77cc176b5ef3b69390a000d/system@00050026436d41e7-97988bddae2f5f40.journal~,
O_RDONLY|O_CLOEXEC) = 25
fstat(25, {st_mode=S_IFREG|0755, st_size=8388608, ...}) = 0
mmap(NULL, 4096, PROT_READ, MAP_SHARED, 25, 0) = 0x7f36cf8f9000
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++
There is no significant CPU activity either.
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-53.4
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1
ii libblkid1 2.20.1-5.11
ii libc6 2.19-11
ii libcap2 1:2.24-6
ii libcap2-bin 1:2.24-6
ii libcryptsetup4 2:1.6.6-1
ii libgcrypt20 1.6.2-3
ii libkmod218-3
ii liblzma55.1.1alpha+20120614-2
ii libpam0g1.1.8-3.1
ii libselinux1 2.3-2
ii libsystemd0 215-5+b1
ii sysv-rc 2.88dsf-53.4
ii udev215-5+b1
ii util-linux 2.20.1-5.11
Versions of packages systemd recommends:
ii dbus1.8.8-1+b1
ii libpam-systemd 215-5+b1
Versions of packages systemd suggests:
pn systemd-ui none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763652: systemd: boot failed, can't execute /bin/plymouth
reopen 763652 bye On 10/01/2014 11:57 AM, Nikolaus Rath wrote: On 10/01/2014 11:05 AM, Michael Biebl wrote: Am 01.10.2014 um 18:49 schrieb Nikolaus Rath: On 10/01/2014 09:22 AM, Michael Biebl wrote: Am 01.10.2014 um 17:46 schrieb Nikolaus Rath: Package: systemd Version: 208-8 Severity: normal Hello, My last attempt to boot this system but me into systemd's emergency mode. Runnig journalctl -xb showed that it failed to start plymouth, trying to execute /bin/plymouth failed with (IIRC) exit code 2. That is most likely a red herring. The plymouth error is not fatal and therefore most likely not the reason why you ended up in emergency mode. Do you have the journal log from that boot which failed? I tried to retrieve them with journalctl -b -1 after restart, but that failed (see other bug report). Is there another way to retrieve them (now that I have rebooted)? Since you did not have persistent logs enabled, those messages are most likely gone. When emergency mode is triggered, rsyslog has not started yet. I think with the given information, it's best to close this bug report and reopen it, in case you encounter the issue again. In that case, when in emergency mode, please save the output of the following commands journalctl -alb systemd-analyze dump systemctl list-units --failed Do you agree? Sure, will do. It happened again. System got stuck in emergency mode on first boot, but booted fine after reboot. I have attached the requested files. Note that the 'systemd-analyze dump' output really was empty. Best, -Nikolaus -- Logs begin at Thu 2014-10-02 08:33:05 PDT, end at Mon 2014-10-06 08:58:33 PDT. -- Oct 06 08:56:25 nelarikon systemd-journal[226]: Runtime journal is using 8.0M (max allowed 320.7M, trying to leave 481.1M free of 3.1G available → current limit 320.7M). Oct 06 08:56:25 nelarikon systemd-journal[226]: Runtime journal is using 8.0M (max allowed 320.7M, trying to leave 481.1M free of 3.1G available → current limit 320.7M). Oct 06 08:56:25 nelarikon kernel: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29 Oct 06 08:56:25 nelarikon kernel: Initializing cgroup subsys cpuset Oct 06 08:56:25 nelarikon kernel: Initializing cgroup subsys cpu Oct 06 08:56:25 nelarikon kernel: Initializing cgroup subsys cpuacct Oct 06 08:56:25 nelarikon kernel: Linux version 3.16-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1 SMP Debian 3.16.3-2 (2014-09-20) Oct 06 08:56:25 nelarikon kernel: Command line: BOOT_IMAGE=/vmlinuz-3.16-2-amd64 root=/dev/mapper/vg0-root ro quiet Oct 06 08:56:25 nelarikon kernel: e820: BIOS-provided physical RAM map: Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0x-0x00091bff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0x00091c00-0x0009] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0x000e-0x000f] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0x0010-0xdaf09fff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdaf0a000-0xdaff] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdb00-0xdb74dfff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdb74e000-0xdb7f] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdb80-0xdbfb3fff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdbfb4000-0xdbff] ACPI data Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdc00-0xdd709fff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdd70a000-0xdd7f] ACPI NVS Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdd80-0xdeee0fff] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdeee1000-0xdf0d] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdf0e-0xdf122fff] ACPI NVS Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xdf123000-0xdf7f] usable Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xf800-0xfbff] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xfec0-0xfec00fff] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xfed0-0xfed03fff] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xfed1c000-0xfed1] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xfee0-0xfee00fff] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0xff00-0x] reserved Oct 06 08:56:25 nelarikon kernel: BIOS-e820: [mem 0x0001-0x00041dff] usable Oct 06 08:56:25 nelarikon kernel: NX (Execute Disable) protection: active Oct 06 08:56:25 nelarikon kernel: SMBIOS 2.7 present. Oct 06 08:56:25 nelarikon
Bug#763652: systemd: boot failed, can't execute /bin/plymouth
On 10/01/2014 09:22 AM, Michael Biebl wrote: Am 01.10.2014 um 17:46 schrieb Nikolaus Rath: Package: systemd Version: 208-8 Severity: normal Hello, My last attempt to boot this system but me into systemd's emergency mode. Runnig journalctl -xb showed that it failed to start plymouth, trying to execute /bin/plymouth failed with (IIRC) exit code 2. That is most likely a red herring. The plymouth error is not fatal and therefore most likely not the reason why you ended up in emergency mode. Do you have the journal log from that boot which failed? I tried to retrieve them with journalctl -b -1 after restart, but that failed (see other bug report). Is there another way to retrieve them (now that I have rebooted)? Best, -Nikolaus -- Nikolaus Rath, Ph.D. Senior Scientist Tri Alpha Energy, Inc. +1 949 830 2117 ext 211 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763654: /bin/journalctl: journalctl --boot option doesn't work: Cannot assign requested address
On 10/01/2014 09:23 AM, Michael Biebl wrote: Am 01.10.2014 um 17:36 schrieb Nikolaus Rath: Package: systemd Version: 208-8 Severity: normal File: /bin/journalctl Hello, I'm trying to retrieve the logs from the last book. journalctl(1) says: -b [ID][±offset], --boot=[ID][±offset] Show messages from a specific boot. This will add a match for _BOOT_ID=. The argument may be empty, in which case logs for the current boot will be shown. If the boot ID is omitted, a positive offset will look up the boots starting from the beginning of the journal, and a equal-or-less-than zero offset will look up boots starting from the end of the journal. Thus, 1 means the first boot found in the journal in the chronological order, 2 the second and so on; while -0 is the last boot, -1 the boot before that, and so on. An empty offset is equivalent to specifying -0, except when the current boot is not the last boot (e.g. because --directory was specified to look at logs from a different machine). However, [0] nelarikon:~# journalctl -b -1 Failed to look up boot -1: Cannot assign requested address [1] nelarikon:~# journalctl --boot=-1 Failed to look up boot -1: Cannot assign requested address I do assume that you have created a /var/log/journal directory? No, I did not. Since journalctl -xb was working out of the box, I was assuming journalctl -b -1 would work as well. I'll setup /var/log/journal as described in README.Debian (only looked at that now). Best, -Nikolaus -- Nikolaus Rath, Ph.D. Senior Scientist Tri Alpha Energy, Inc. +1 949 830 2117 ext 211 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763652: systemd: boot failed, can't execute /bin/plymouth
On 10/01/2014 11:05 AM, Michael Biebl wrote: Am 01.10.2014 um 18:49 schrieb Nikolaus Rath: On 10/01/2014 09:22 AM, Michael Biebl wrote: Am 01.10.2014 um 17:46 schrieb Nikolaus Rath: Package: systemd Version: 208-8 Severity: normal Hello, My last attempt to boot this system but me into systemd's emergency mode. Runnig journalctl -xb showed that it failed to start plymouth, trying to execute /bin/plymouth failed with (IIRC) exit code 2. That is most likely a red herring. The plymouth error is not fatal and therefore most likely not the reason why you ended up in emergency mode. Do you have the journal log from that boot which failed? I tried to retrieve them with journalctl -b -1 after restart, but that failed (see other bug report). Is there another way to retrieve them (now that I have rebooted)? Since you did not have persistent logs enabled, those messages are most likely gone. When emergency mode is triggered, rsyslog has not started yet. I think with the given information, it's best to close this bug report and reopen it, in case you encounter the issue again. In that case, when in emergency mode, please save the output of the following commands journalctl -alb systemd-analyze dump systemctl list-units --failed Do you agree? Sure, will do. Best, -Nikolaus -- Nikolaus Rath, Ph.D. Senior Scientist Tri Alpha Energy, Inc. +1 949 830 2117 ext 211 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760425: uml-utilities: tun/tap permissions not set correctly on boot
Package: uml-utilities Version: 20070815-1.3 Severity: normal After boot, I have: # ls -l /dev/net/ total 0 crw-rw 1 root root 10, 200 Sep 3 16:47 tun Bringing the interface down and up again restores correct permissions (so that user nikratio has access): # ifdown tap0 # ifup tap0 Set 'tap0' persistent and owned by uid 1000 # ls -l /dev/net/ total 0 crw-rw 1 root uml-net 10, 200 Sep 3 16:47 tun My interface definition is: # cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug eth0 auto eth0 iface eth0 inet manual auto tap0 iface tap0 inet manual tunctl_user nikratio auto br0 iface br0 inet dhcp bridge_ports eth0 tap0 bridge_hw c8:60:00:bf:a2:7f -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages uml-utilities depends on: ii adduser 3.113+nmu3 ii libc6 2.19-10 ii libfuse2 2.9.3-15 ii libreadline6 6.3-8 ii lsb-base 4.1+Debian13 uml-utilities recommends no packages. Versions of packages uml-utilities suggests: pn user-mode-linux none -- Configuration Files: /etc/default/uml-utilities changed: UML_SWITCH_START=false -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758013: s3ql autopkg test regression
On 08/20/2014 03:14 AM, Matthias Klose wrote: Am 20.08.2014 um 06:52 schrieb Nikolaus Rath: If someone cares deeply about this, the necessary patch is at https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/. I did not add it to the debian package yet because I considered it a minor issue that I did not want to bug my sponsor with. But if some DD wants to sponsor a new upload right away to get this fixed, I'm happy to update the package in SVN. sure, I can do this. SVN is updated. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758013: s3ql autopkg test regression
On 08/19/2014 01:33 AM, Matthias Klose wrote: Control: severity -1 important Care to provide a justification? There is no bug in the program itself, so I don't see how this is has a major effect on the usability of a package. That's a bug in the test (race condition) rather than in the program. It's fixed upstream. Nikolaus, I find this kind of attitude rather disturbing. If you don't care about the autopkg tests, and if you are not ready to fix these but rather wait for the fixes from upstream (and maybe new bugs), then I think it's better to drop the autopkg tests. What makes you think I'm not ready to fix them? And even if was my intention to wait for a new upstream version instead, I think I'm a bit more qualified than you to judge if that's a good idea or not. And replying to the bug report without replying to the maintainer is at least odd. What do you mean? I am the maintainer. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758013: s3ql autopkg test regression
Simon McVittie s...@debian.org writes: On 19/08/14 09:33, Matthias Klose wrote: [Nikolaus Rath wrote:] That's a bug in the test (race condition) rather than in the program. It's fixed upstream. [...] If you don't care about the autopkg tests, and if you are not ready to fix these but rather wait for the fixes from upstream (and maybe new bugs), then I think it's better to drop the autopkg tests. There are always at least two possible reasons for a failing test: the code under test is wrong or the test is wrong. The most important thing is that someone with knowledge of the package has looked at the failure report and triaged it, i.e. assigned it an appropriate priority based on their knowledge of the package. It appears Nikolaus has done this, and it will be dealt with when it's dealt with. I don't think there's a problem here. If someone cares deeply about this, the necessary patch is at https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/. I did not add it to the debian package yet because I considered it a minor issue that I did not want to bug my sponsor with. But if some DD wants to sponsor a new upload right away to get this fixed, I'm happy to update the package in SVN. Otherwise I'll wait for a new upstream version. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758013: s3ql autopkg test regression
On 08/13/2014 03:18 AM, Matthias Klose wrote:
http://ci.debian.net/data/packages/unstable/amd64/s/s3ql/20140811_044901.autopkgtest.log
=== FAILURES
===
__ NewerMetadataTest.test_all
__
Traceback (most recent call last):
File /tmp/adt-run.ZCEVkj/build.2re/s3ql-2.10.1+dfsg/tests/t4_fuse.py, line
161, in test_all
return self.runTest()
File /tmp/adt-run.ZCEVkj/build.2re/s3ql-2.10.1+dfsg/tests/t5_failsafe.py,
line 131, in runTest
fh.write('foobar')
File /usr/lib/python3/dist-packages/_pytest/python.py, line 1054, in
__exit__
pytest.fail(DID NOT RAISE)
File /usr/lib/python3/dist-packages/_pytest/runner.py, line 467, in fail
raise Failed(msg=msg, pytrace=pytrace)
Failed: DID NOT RAISE
That's a bug in the test (race condition) rather than in the program.
It's fixed upstream.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757715: RM: s3ql [sparc] -- ROM; sparc is not supported
Package: ftp.debian.org Severity: normal Hello, Could you please remove the s3ql package for the sparc architecture? Since the last release, the unit tests on sparc have started to fail on the buildds, and I (as both maintainer and upstream) have no way to reproduce the problem nor any idea of how to debug this or fix it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757742: python-systemd: Please provide python3-systemd
Source: python-systemd
Severity: normal
Tags: patch
Hello,
Could you please provide systemd bindings for Python 3 as well?
I have attached a patch that might work. I wasn't able to test this
because for me systemd currently fails to build from source:
/usr/include/x86_64-linux-gnu/sys/xattr.h:32:3: error: expected identifier
before numeric constant
XATTR_CREATE = 1, /* set value, fail if attr already exists. */
^
Makefile:9750: recipe for target 'src/core/libsystemd_core_la-socket.lo' failed
make[4]: *** [src/core/libsystemd_core_la-socket.lo] Error 1
If someone tells me how to fix or work around that, I'll be happy to
help with the Python 3 package.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -ur systemd-208/debian/control systemd-208.new/debian/control
--- systemd-208/debian/control 2014-07-15 15:44:42.0 -0700
+++ systemd-208.new/debian/control 2014-08-10 18:24:25.757041485 -0700
@@ -38,6 +38,7 @@
libgirepository1.0-dev (= 1.31.1),
gobject-introspection (= 1.31.1),
python-dev,
+ python3-dev,
libglib2.0-doc
Package: systemd
@@ -353,6 +354,16 @@
Description: python bindings for systemd
This package contains Python bindings for the systemd libraries.
+Package: python3-systemd
+Section: python
+Priority: optional
+Architecture: linux-any
+Depends: ${shlibs:Depends},
+ ${misc:Depends},
+ ${python3:Depends}
+Description: python 3 bindings for systemd
+ This package contains Python 3 bindings for the systemd libraries.
+
Package: systemd-dbg
Architecture: linux-any
Section: debug
diff -ur systemd-208/debian/rules systemd-208.new/debian/rules
--- systemd-208/debian/rules 2014-07-15 15:44:42.0 -0700
+++ systemd-208.new/debian/rules 2014-08-10 18:23:36.253469199 -0700
@@ -218,7 +218,7 @@
%:
ifeq (,$(findstring stage1,$(DEB_BUILD_PROFILES)))
- dh $@ --with autoreconf,gir,python2
+ dh $@ --with autoreconf,gir,python2,python3
else
- dh $@ --with autoreconf,python2 $(BOOTSTRAP_DH_FLAGS)
+ dh $@ --with autoreconf,python2,python3 $(BOOTSTRAP_DH_FLAGS)
endif
Bug#757753: /boot/vmlinuz-3.14-2-amd64: btrfs stuck in scrub, no way to recover
Package: src:linux Version: 3.14.13-2 Severity: normal File: /boot/vmlinuz-3.14-2-amd64 Hello, I started a scrub of one of my btrfs filesystem and then had to restart the system. `systemctl restart` seemed to terminate all processes, but then got stuck at the end. The disk activity led was still flashing rapidly at that point, so I assume that the active scrub was preventing the reboot (is that a bug or a feature?). In any case, I could not wait for that so I power cycled. But now my file system seems to be stuck in a scrub that can neither be completed nor cancelled: $ sudo btrfs scrub status /home/nikratio/ scrub status for 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 scrub started at Sun Aug 10 18:36:43 2014, running for 1562 seconds total bytes scrubbed: 209.97GiB with 0 errors $ date Sun Aug 10 22:00:44 PDT 2014 $ sudo btrfs scrub cancel /home/nikratio/ ERROR: scrub cancel failed on /home/nikratio/: not running [2] nikratio@vostro:~/tmp $ sudo btrfs scrub start /home/nikratio/ ERROR: scrub is already running. To cancel use 'btrfs scrub cancel /home/nikratio/'. To see the status use 'btrfs scrub status [-d] /home/nikratio/'. -- Package-specific info: ** Version: Linux version 3.14-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-5) ) #1 SMP Debian 3.14.13-2 (2014-07-24) ** Command line: BOOT_IMAGE=/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-debian ro quiet init=/bin/systemd ** Not tainted ** Kernel log: [ 21.993720] nouveau [ DRM] TMDS table version 2.0 [ 21.993721] nouveau [ DRM] DCB version 4.0 [ 21.993723] nouveau [ DRM] DCB outp 00: 01000f02 00020030 [ 21.993724] nouveau [ DRM] DCB outp 01: 02000f00 [ 21.993725] nouveau [ DRM] DCB outp 02: 08011f82 00020030 [ 21.993726] nouveau [ DRM] DCB outp 03: 02022f62 00020010 [ 21.993727] nouveau [ DRM] DCB outp 04: 04833fb6 0f420010 [ 21.993728] nouveau [ DRM] DCB outp 05: 04033f72 00020010 [ 21.993729] nouveau [ DRM] DCB conn 00: 1030 [ 21.993731] nouveau [ DRM] DCB conn 01: 00020131 [ 21.993732] nouveau [ DRM] DCB conn 02: 00010261 [ 21.993733] nouveau [ DRM] DCB conn 03: 2346 [ 21.994670] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 21.994671] [drm] Driver supports precise vblank timestamp query. [ 22.004790] nouveau [ DRM] MM: using COPY for buffer copies [ 22.136617] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872, rev 0202 detected [ 22.154145] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected [ 22.170754] nouveau [ DRM] allocated 2048x1152 fb: 0x8, bo 880215097800 [ 22.170793] fbcon: nouveaufb (fb0) is primary device [ 22.235324] Console: switching to colour frame buffer device 256x72 [ 22.237115] nouveau :01:00.0: fb0: nouveaufb frame buffer device [ 22.237116] nouveau :01:00.0: registered panic notifier [ 22.237119] [drm] Initialized nouveau 1.1.1 20120801 for :01:00.0 on minor 0 [ 22.237149] hda_intel: Disabling MSI [ 22.237155] hda-intel :01:00.1: Handle VGA-switcheroo audio client [ 22.237263] snd_hda_intel :00:1b.0: irq 61 for MSI/MSI-X [ 22.394490] usb_audio: Warning! Unlikely big volume range (=34656), cval-res is probably wrong. [ 22.394492] usb_audio: [3] FU [Mic Capture Volume] ch = 1, val = -32768/1888/16[ 22.394665] usbcore: registered new interface driver snd-usb-audio [ 22.500364] iTCO_vendor_support: vendor-support=0 [ 22.514700] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [ 22.514758] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [ 22.514885] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 22.555322] asus_wmi: ASUS WMI generic driver loaded [ 22.629377] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 22.642575] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card0/input18 [ 22.642661] input: HDA Intel PCH Line Out Side as /devices/pci:00/:00:1b.0/sound/card0/input17 [ 22.642730] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card0/input16 [ 22.642798] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 22.642862] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 22.642934] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card0/input13 [ 22.643030] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card0/input12 [ 22.643197] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card0/input11 [ 22.655209] asus_wmi: Initialization: 0x0 [ 22.655242] asus_wmi: BIOS WMI version: 0.9 [ 22.655293] asus_wmi: SFUN value: 0x0 [ 22.655666] input: Eee PC WMI hotkeys as /devices/platform/eeepc-wmi/input/input19 [ 22.656410] asus_wmi: Disabling ACPI video driver [ 22.898930]
Bug#756970: /boot/vmlinuz-3.14-2-amd64: kernel BUG at ..linux-3.14.13/fs/btrfs/ctree.c:3215!
On 08/05/2014 07:01 PM, Ben Hutchings wrote: On Sun, 2014-08-03 at 20:27 -0700, Nikolaus Rath wrote: Package: src:linux Version: 3.14.13-2 Severity: normal File: /boot/vmlinuz-3.14-2-amd64 I was peacefully transferring a big file to my external USB harddisk formatted with btrfs, when the kernel brutally lashed out with the BUG below, preventing all further access to the disk: Is it possible that you filled up the disk? I have heard that this is a difficult question to answer with btrfs. My gut feeling is no, there should be plenty of space available. Here's what btrfs says: # btrfs filesystem df /mnt/backup/ Data, single: total=450.01GiB, used=437.52GiB System, DUP: total=8.00MiB, used=60.00KiB System, single: total=4.00MiB, used=0.00 Metadata, DUP: total=3.00GiB, used=2.13GiB Metadata, single: total=8.00MiB, used=0.00 # df -h /mnt/backup/ Filesystem Size Used Avail Use% Mounted on /dev/dm-9 699G 442G 256G 64% /mnt/backup # btrfs filesystem show /mnt/backup Label: 'backup' uuid: 11443bd3-7e74-46cc-8140-c7fbb14f9669 Total devices 2 FS bytes used 439.20GiB devid1 size 465.76GiB used 455.04GiB path /dev/dm-9 devid2 size 232.83GiB used 1.00GiB path /dev/mapper/usb_backup1 For what it's worth, the error occurred when overwriting a 21 GB file with 'bar'. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756245: systemd: 204 - 208 upgrade sometimes breaks resume from hibernation
Hi, Maybe the correlation with the systemd upgrade is a coincidence. I've kept track of the problems in more detail now. While with 208 about 10 in 20 resumes fail, I've also had 2 failures in 20 with systemd 204. (this still doesn't explain why I had zero failures with the tens of resumes before 7/21 though). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756970: /boot/vmlinuz-3.14-2-amd64: kernel BUG at ..linux-3.14.13/fs/btrfs/ctree.c:3215!
Package: src:linux Version: 3.14.13-2 Severity: normal File: /boot/vmlinuz-3.14-2-amd64 I was peacefully transferring a big file to my external USB harddisk formatted with btrfs, when the kernel brutally lashed out with the BUG below, preventing all further access to the disk: -- Package-specific info: ** Version: Linux version 3.14-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-5) ) #1 SMP Debian 3.14.13-2 (2014-07-24) ** Command line: BOOT_IMAGE=/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-debian ro quiet init=/bin/systemd ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [ 5659.098451] BTRFS info (device dm-9): disk space caching is enabled [ 7516.376999] BTRFS: device fsid 8742472d-a9b0-4ab6-b67a-5d21f14f7a38 devid 1 transid 164974 /dev/mapper/vg0-nikratio_crypt [ 8239.129310] [ cut here ] [ 8239.129328] kernel BUG at /build/linux-C0Ywsc/linux-3.14.13/fs/btrfs/ctree.c:3215! [ 8239.129346] invalid opcode: [#1] SMP [ 8239.129359] Modules linked in: btusb binfmt_misc bridge stp llc tun ext4 mbcache jbd2 uvcvideo videobuf2_vmalloc videobuf2_memops ath3k videobuf2_core bluetooth 6lowpan_iphc videodev eeepc_wmi media asus_wmi sparse_keymap crc16 iTCO_wdt iTCO_vendor_support evdev snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device nouveau arc4 mxm_wmi rt2800pci snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ttm rt2800mmio snd_hda_intel rt2800lib snd_hda_codec rt2x00pci rt2x00mmio rt2x00lib eeprom_93cx6 mei_me mac80211 drm_kms_helper drm mei snd_hwdep cfg80211 crc_ccitt rfkill snd_pcm snd_timer i2c_algo_bit snd lpc_ich mfd_core i2c_i801 i2c_core shpchp soundcore battery wmi video button x86_pkg_temp_thermal intel_powerclamp psmouse serio_raw intel_rapl pcspkr processor kvm_intel kvm hwmon_vid coretemp loop fuse parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq sha256_ssse3 sha256_generic dm_crypt hid_generic usbhid usb_storage hid dm_mod sg sd_mod crc_t10dif sr_mod crct10di f_generic cdrom crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata ehci_pci xhci_hcd ehci_hcd scsi_mod e1000e usbcore ptp usb_common pps_core thermal fan thermal_sys [ 8239.129735] CPU: 1 PID: 11122 Comm: btrfs-endio-wri Not tainted 3.14-2-amd64 #1 Debian 3.14.13-2 [ 8239.129755] Hardware name: System manufacturer System Product Name/P8Z68-V GEN3, BIOS 3603 11/09/2012 [ 8239.129777] task: 880215748ce0 ti: 88000ae38000 task.ti: 88000ae38000 [ 8239.129794] RIP: 0010:[a029c870] [a029c870] btrfs_set_item_key_safe+0x170/0x180 [btrfs] [ 8239.129823] RSP: 0018:88000ae39bc0 EFLAGS: 00010286 [ 8239.129836] RAX: RBX: 0014 RCX: dd0d4000 [ 8239.129853] RDX: RSI: 88000ae39cc7 RDI: 88000ae39bd7 [ 8239.129869] RBP: 8801d6e7a2f0 R08: 1000 R09: 88000ae39be0 [ 8239.129885] R10: R11: R12: 88000ae39bc6 [ 8239.129902] R13: 88018033ca00 R14: 8801ca3f4000 R15: 88000ae39cc7 [ 8239.129918] FS: () GS:88021ec4() knlGS: [ 8239.129937] CS: 0010 DS: ES: CR0: 80050033 [ 8239.129950] CR2: 7ffbe5f3f000 CR3: 000190fc4000 CR4: 000407e0 [ 8239.129966] Stack: [ 8239.129972] 0686 006c 86dd0d30 6c06 [ 8239.129992] dd0d3000 8801d6e7a2f0 dd0d4000 [ 8239.130013] 88018033ca00 dd0e8000 0ba7 a02d28d8 [ 8239.130033] Call Trace: [ 8239.130046] [a02d28d8] ? __btrfs_drop_extents+0x4c8/0xc60 [btrfs] [ 8239.130068] [a02c310b] ? insert_reserved_file_extent.constprop.55+0x9b/0x300 [btrfs] [ 8239.130093] [a02c8d63] ? btrfs_finish_ordered_io+0x2d3/0x560 [btrfs] [ 8239.130116] [a02ecd30] ? worker_loop+0x140/0x520 [btrfs] [ 8239.130135] [a02ecbf0] ? btrfs_queue_worker+0x300/0x300 [btrfs] [ 8239.130152] [81080a68] ? kthread+0xb8/0xd0 [ 8239.130165] [810809b0] ? kthread_create_on_node+0x170/0x170 [ 8239.130181] [814d2c4c] ? ret_from_fork+0x7c/0xb0 [ 8239.130195] [810809b0] ? kthread_create_on_node+0x170/0x170 [ 8239.130210] Code: 7c 24 17 4c 89 fe 48 89 44 24 20 0f b6 44 24 0e 88 44 24 1f 48 8b 44 24 06 48 89 44 24 17 e8 68 f2 ff ff 85 c0 0f 8f 47 ff ff ff 0f 0b 0f 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 55 48 b8 00 [ 8239.130321] RIP [a029c870] btrfs_set_item_key_safe+0x170/0x180 [btrfs] [ 8239.130342] RSP 88000ae39bc0 [ 8239.137238] ---[ end trace d56db635f52d9d4d ]--- ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc.
Bug#756245: systemd: 204 - 208 upgrade sometimes breaks resume from hibernation
On 07/27/2014 03:19 PM, Michael Biebl wrote: Am 27.07.2014 23:55, schrieb Nikolaus Rath: Package: systemd Version: 208-6 Severity: normal I am using systemd as pid 1. After a dist-upgrade on July 21st for testing, I was unable to resume from hibernation anymore. The resume image would be loaded, but then the system would reboot. systemd is not involved in the actual resume, that's entirely done in the initramfs. So I doubt this is related to systemd. Do you maybe have upgraded the kernel itself? No, definitely not: $ ls -l /boot total 22012 -rw-r--r-- 1 root root 153316 Jul 12 16:34 config-3.14-1-amd64 drwxr-xr-x 5 root root12288 Jul 15 20:38 grub/ -rw-r--r-- 1 root root 16986306 Jul 27 14:41 initrd.img-3.14-1-amd64 drwx-- 2 root root16384 Jan 13 2013 lost+found/ -rw-r--r-- 1 root root 2418515 Jul 12 16:34 System.map-3.14-1-amd64 -rw-r--r-- 1 root root 2944720 Jul 12 16:24 vmlinuz-3.14-1-amd64 But it does seem that upgrading/downgrading systemd has triggered a rebuild of the initramfs. The only packages that were downgraded together (presumably because of dependencies) were: libpam-systemd libsystemd-daemon0 libsystemd-journal0 libsystemd-journal0:i386 libsystemd-login0 libudev1 libudev1:i386 systemd systemd-sysv udev Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: OpenPGP digital signature
Bug#755358: s3ql: FTBFS on kfreebsd-* + s390x: test failures
I have no idea why the test would time out on s390x. Especially since it's unchanged since the last release - which built just fine on s390x. I will fix the kFreeBSD bugs and hope that the s390x problem was a fluke that's going to disappear on the next build without me doing anything. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
