Bug#828482: bug 828482 fix
On 2017-02-01 09:59:02 [+0800], Di-Shi Sun wrote: > Hi Sebastian, Hi Di-Shi, > I am pretty sure that 4.11.3+dfsg-1 is not influenced by 828482 (FTBFS with > openssl 1.1.0). Please send us the build log showing the issue you report. sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on debbuildd +==+ | osptoolkit 4.11.3+dfsg-1 (amd64) Wed, 01 Feb 2017 07:30:45 + | +==+ Package: osptoolkit Version: 4.11.3+dfsg-1 Source Version: 4.11.3+dfsg-1 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: any +--+ | Build environment| +--+ Kernel: Linux 4.9.0-1-amd64 amd64 (x86_64) Toolchain package versions: binutils_2.27.90.20170124-2 dpkg-dev_1.18.21 g++-6_6.3.0-5 gcc-6_6.3.0-5 libc6-dev_2.24-9 libstdc++-6-dev_6.3.0-5 libstdc++6_6.3.0-5 linux-libc-dev_4.9.6-3 Package versions: adduser_3.115 apt_1.4~beta4 autoconf_2.69-10 automake_1:1.15-6 autopoint_0.19.8.1-2 autotools-dev_20161112.1 base-files_9.8 base-passwd_3.5.43 bash_4.4-4 binutils_2.27.90.20170124-2 bsdmainutils_9.0.12 bsdutils_1:2.29.1-1 build-essential_12.3 bzip2_1.0.6-8.1 coreutils_8.26-2 cpp_4:6.3.0-1 cpp-6_6.3.0-5 dash_0.5.8-2.4 debconf_1.5.60 debhelper_10.2.5 debian-archive-keyring_2014.3 debianutils_4.8.1 dh-autoreconf_13 dh-strip-nondeterminism_0.029-2 diffutils_1:3.5-3 dmsetup_2:1.02.137-1 docbook_4.5-6 docbook-to-man_1:2.0.0-35 dpkg_1.18.21 dpkg-dev_1.18.21 e2fslibs_1.43.4-1 e2fsprogs_1.43.4-1 eatmydata_105-5 fakeroot_1.21-3.1 file_1:5.29-3 findutils_4.6.0+git+20161106-1 g++_4:6.3.0-1 g++-6_6.3.0-5 gcc_4:6.3.0-1 gcc-6_6.3.0-5 gcc-6-base_6.3.0-5 gettext_0.19.8.1-2 gettext-base_0.19.8.1-2 gnupg_2.1.18-3 gnupg-agent_2.1.18-3 gpgv_2.1.18-3 grep_2.27-2 groff-base_1.22.3-9 gzip_1.6-5 hostname_3.18 init_1.47 init-system-helpers_1.47 initscripts_2.88dsf-59.8 insserv_1.14.0-5.4 intltool-debian_0.35.0+20060710.4 libacl1_2.2.52-3 libapparmor1_2.11.0-2 libapt-pkg5.0_1.4~beta4 libarchive-zip-perl_1.59-1 libasan3_6.3.0-5 libassuan0_2.4.3-2 libatomic1_6.3.0-5 libattr1_1:2.4.47-2 libaudit-common_1:2.6.7-1 libaudit1_1:2.6.7-1 libblkid1_2.29.1-1 libbsd0_0.8.3-1 libbz2-1.0_1.0.6-8.1 libc-bin_2.24-9 libc-dev-bin_2.24-9 libc6_2.24-9 libc6-dev_2.24-9 libcap-ng0_0.7.7-3 libcap2_1:2.25-1 libcap2-bin_1:2.25-1 libcc1-0_6.3.0-5 libcilkrts5_6.3.0-5 libcomerr2_1.43.4-1 libcroco3_0.6.11-2 libcryptsetup4_2:1.7.3-3 libdb5.3_5.3.28-12+b1 libdebconfclient0_0.221 libdevmapper1.02.1_2:1.02.137-1 libdpkg-perl_1.18.21 libeatmydata1_105-5 libfakeroot_1.21-3.1 libfdisk1_2.29.1-1 libffi6_3.2.1-6 libfile-stripnondeterminism-perl_0.029-2 libgcc-6-dev_6.3.0-5 libgcc1_1:6.3.0-5 libgcrypt20_1.7.6-1 libgdbm3_1.8.3-14 libglib2.0-0_2.50.2-2 libgmp10_2:6.1.2+dfsg-1 libgomp1_6.3.0-5 libgpg-error0_1.26-2 libicu57_57.1-5 libidn11_1.33-1 libip4tc0_1.6.0+snapshot20161117-5 libisl15_0.18-1 libitm1_6.3.0-5 libkmod2_23-2 libksba8_1.3.5-2 liblsan0_6.3.0-5 liblz4-1_0.0~r131-2 liblzma5_5.2.2-1.2 libmagic-mgc_1:5.29-3 libmagic1_1:5.29-3 libmount1_2.29.1-1 libmpc3_1.0.3-1 libmpfr4_3.1.5-1 libmpx2_6.3.0-5 libncurses5_6.0+20161126-1 libncursesw5_6.0+20161126-1 libnpth0_1.3-1 libosp5_1.5.2-13 libpam-modules_1.1.8-3.5 libpam-modules-bin_1.1.8-3.5 libpam-runtime_1.1.8-3.5 libpam0g_1.1.8-3.5 libpcre3_2:8.39-2 libperl5.24_5.24.1-1 libpipeline1_1.4.1-2 libprocps4_2:3.3.10-4+b1 libprocps6_2:3.3.12-3 libquadmath0_6.3.0-5 libreadline6_6.3-9 libreadline7_7.0-2 libseccomp2_2.3.1-2.1 libselinux1_2.6-3 libsemanage-common_2.6-2 libsemanage1_2.6-2 libsepol1_2.6-2 libsigsegv2_2.10-5 libsmartcols1_2.29.1-1 libsqlite3-0_3.16.2-2 libss2_1.43.4-1 libssl-dev_1.1.0d-2 libssl1.1_1.1.0d-2 libstdc++-6-dev_6.3.0-5 libstdc++6_6.3.0-5 libsystemd0_232-14 libtimedate-perl_2.3000-2 libtinfo5_6.0+20161126-1 libtool_2.4.6-2 libtool-bin_2.4.6-2 libtsan0_6.3.0-5 libubsan0_6.3.0-5 libudev1_232-14 libunistring0_0.9.6+really0.9.3-0.1 libusb-0.1-4_2:0.1.12-30 libustr-1.0-1_1.0.4-6 libuuid1_2.29.1-1 libxml2_2.9.4+dfsg1-2.2 linux-libc-dev_4.9.6-3 login_1:4.4-3 lsb-base_9.20161125 m4_1.4.18-1 make_4.1-9 man-db_2.7.6.1-2 mawk_1.3.3-17 mount_2.29.1-1 multiarch-support_2.24-9 ncurses-base_6.0+20161126-1 ncurses-bin_6.0+20161126-1 opensp_1.5.2-13 passwd_1:4.4-3 patch_2.7.5-1 perl_5.24.1-1 perl-base_5.24.1-1 perl-modules-5.24_5.24.1-1 pinentry-curses_1.0.0-1 po-debconf_1.0.20 procps_2:3.3.12-3 readline-common_7.0-2 sbuild-build-depends-core-dummy_0.invalid.0 sbuild-build-depends-osptoolkit-dummy_0.invalid.0 sed_4.3-3 sensible-utils_0.0.9 sgml-base_1.29 sgml-data_2.0.10 startpar_0.59-3.1 systemd_232-14 systemd-sysv_232-14 sysv-rc_2.88dsf-59.8 sysvinit-utils_2.88dsf-59.8
Bug#853817: nautilus: Pressing enter with no selection while in search makes Nautilus crash.
Package: nautilus Version: 3.22.2-1 Severity: upstream please include upstream patch in stretch https://git.gnome.org/browse/nautilus/commit/?id=82a2d53e98758623cc2ebca176391d2d1f639e91 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nautilus depends on: ii desktop-file-utils 0.23-1 ii gsettings-desktop-schemas 3.22.0-1 ii gvfs 1.30.3-1 ii libatk1.0-02.22.0-1 ii libc6 2.24-8 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libexempi3 2.4.0-1 ii libexif12 0.6.21-2 ii libgail-3-03.22.6-1 ii libgdk-pixbuf2.0-0 2.36.3-1 ii libglib2.0-0 2.50.2-2 ii libglib2.0-data2.50.2-2 ii libgnome-autoar-0-00.1.1-4+b1 ii libgnome-desktop-3-12 3.22.2-1 ii libgtk-3-0 3.22.6-1 ii libnautilus-extension1a3.22.2-1 ii libpango-1.0-0 1.40.3-3 ii libselinux12.6-3 ii libtracker-sparql-1.0-01.10.4-1 ii libx11-6 2:1.6.4-2 ii nautilus-data 3.22.2-1 ii shared-mime-info 1.7-1 Versions of packages nautilus recommends: ii gnome-sushi 3.21.91-2 ii gvfs-backends1.30.3-1 ii librsvg2-common 2.40.16-1 Versions of packages nautilus suggests: ii brasero 3.12.1-4 ii eog 3.20.5-1 ii evince [pdf-viewer] 3.22.1-3 ii nautilus-sendto 3.8.4-2 ii okular [pdf-viewer] 4:16.08.2-1 ii totem3.22.0-2+b1 ii tracker 1.10.4-1 ii vlc [mp3-decoder]2.2.4-13 ii xdg-user-dirs0.15-2 -- no debconf information
Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu
Am 2017-02-01 04:45, schrieb Sam Hartman: What I think several of us did is look at the technical details and decide we believe that the installer team was the right set of people to make this technical decision. So, I think the TC will make its decisions on a technical foundation a lot less frequently than you do. That said, I do think an understanding of which technical factors are important is something we need to do. If there are things I can to to help you believe that we did consider the points you think important I'd like to do that. If you can think of things I can do to help you gain confidence that we have heard you, please let me know. That said, I'm hoping you can respect me when I say that hearing you does not mean agreeing with you--not even about what factors are important in making a decision. You got asked as TC to decide which way it should go. Right now you try to shy out of giving an answer to that. Instead you should just decide on it, and if you all think its the installers team to decide and Ole lost, then issue such a statement. Everything else is just another plain fail. -- bye Joerg
Bug#749031: transmission-gtk: Tray icon in mate-panel and gnome-shell has excessive spacing
On Sat, Jan 07, 2017 at 07:19:00PM -0500, Sandro Tosi wrote: > On Fri, Apr 3, 2015 at 1:05 PM, Eric Pruittwrote: > > I don't use Sid, and I'm not particularly interested in mixing stable > > and unstable packages just to test this. I intend to update to Jessie > > when it's released later this month, and I will see if the problem is > > still reproducible at that time. > > any update on this? I just tried running transmission-gtk with trayer, and the spacing issue was not present on Debian 8.7. Eric
Bug#853816: ITP: golang-github-go-openapi-spec -- OpenAPI specification object model
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-go-openapi-spec Version : 0.0~git20161119.0.f7ae86d-1 Upstream Author : Ivan Porto Carrero * URL : https://github.com/go-openapi/spec * License : Apache-2.0 Programming Lang: Go Description : OpenAPI specification object model The OpenAPI Specification is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful Web services. . This module is a Go implementation of the OpenAPI object model which allows web interfaces to be specified and implemented using Go in a simple and elegant manner. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853815: ITP: golang-github-go-openapi-jsonpointer -- Fork of gojsonpointer with support for structs
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-go-openapi-jsonpointer Version : 0.0~git20170102.0.779f453-1 Upstream Author : Ivan Porto Carrero * URL : https://github.com/go-openapi/jsonpointer * License : Apache-2.0 Programming Lang: Go Description : Fork of gojsonpointer with support for structs JSON Pointer is an extension to the JSON format which defines a string syntax for identifying a specific value within a JSON document. . This module is a fork of the github.com/xeipuuv/gojsonpointer project which implements the JSON Pointer standard for Go, but with support for structs added. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#846647: tinyeartrainer: please make the build reproducible
> Would you consider applying this patch and uploading? Friendly ping on this :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#845745: node-rimraf: please make the build reproducible
Hi, > Thank you, and i did that in some other packages recently, > i'll try to fix them. Friendly ping on this? :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#853814: ITP: golang-github-go-openapi-jsonreference -- Fork of gojsonreference with support for structs
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-go-openapi-jsonreference Version : 0.0~git20161105.0.36d33bf-1 Upstream Author : Ivan Porto Carrero * URL : https://github.com/go-openapi/jsonreference * License : Apache-2.0 Programming Lang: Go Description : Fork of gojsonreference with support for structs JSON Reference is an extension to the JSON format which allows a JSON value to reference another value within a JSON document. . This module is a fork of the github.com/xeipuuv/gojsonreference project which implements the JSON Reference standard for Go, but with support for structs added. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853813: ITP: golang-github-go-openapi-swag -- General utilities for the go-openapi projects
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-go-openapi-swag Version : 0.0~git20161024.0.3b6d86c-1 Upstream Author : Ivan Porto Carrero * URL : https://github.com/go-openapi/swag * License : Apache-2.0 Programming Lang: Go Description : General utilities for the go-openapi projects This modules contains a collection of helper functions used in many of the go-openapi projects. It includes utilities to: . * convert between value and pointers for builtins * convert from string to builtin * fast json concatenation signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853812: vdr: [INTL:ru] Russian debconf templates translation update
Package: vdr Version: 2.2.0-6 Severity: wishlist Tags: l10n patch Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** Russian debconf templates translation update is attached. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ru.po.gz Description: application/gzip
Bug#853811: ITP: golang-github-mailru-easyjson -- Fast JSON serializer for golang
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-mailru-easyjson Version : 0.0~git20161103.0.159cdb8-1 Upstream Author : Victor Starodub * URL : https://github.com/mailru/easyjson * License : Expat Programming Lang: Go Description : Fast JSON serializer for golang The easyjson library allows the user to (un-)marshal JSON structs without the use of reflection by generating marshaller code. . One of the aims of the library is to keep generated code simple enough so that it can be easily optimized or fixed. Another goal is to provide users with ability to customize the generated code not available in 'encoding/json', such as generating snake_case names or enabling 'omitempty' behavior by default. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853810: ITP: verboselogs -- Verbose logging level for Python's logging module
Package: wnpp Severity: wishlist Owner: Gaurav Juvekar* Package name: verboselogs Version : 1.5 Upstream Author : Peter Odding * URL : https://verboselogs.readthedocs.io * License : Expat Programming Lang: Python Description : Verbose logging level for Python's logging module Binary package names: python3-verboselogs python-verboselogs The verboselogs package extends Python's logging module to add the log levels VERBOSE, NOTICE, and SPAM: - The VERBOSE level sits between the predefined INFO and DEBUG levels. - The NOTICE level sits between the predefined WARNING and INFO levels. - The SPAM level sits between the predefined DEBUG and NOTSET levels. This package is a dependency for coloredlogs (ITP #780187) This package will be maintained in the Python modules team. -- Regards, Gaurav Juvekar signature.asc Description: OpenPGP digital signature
Bug#850951: CVE-2016-9962
On 31 January 2017 at 20:46, Tianon Graviwrote: > I'm preparing a patch for the package now, but I'm curious what the > implications of an upload will be so close to the freeze -- do we need > to request a freeze exception or a migration adjustment after the > updated package is up? Should I hold off on uploading? (would rather > not lose "runc" from stretch) CVE fix backported for v0.1.1 is attached (applies cleanly in the current packaging when added to "debian/patches/series"). Happy to do the actual upload if I can get some guidance on how to make sure it's done properly WRT freeze (or just as happy to leave it to someone else). O:) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 Description: set "runc exec" processes as non-dumpable (CVE-2016-9962) Origin: https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5 (backported to v0.1.1) Author: Tianon Gravi Forwarded: not-needed Applied-Upstream: > 1.0.0-rc2 diff --git a/libcontainer/nsenter/nsexec.c b/libcontainer/nsenter/nsexec.c index 8f37d6c..3c74c63 100644 --- a/libcontainer/nsenter/nsexec.c +++ b/libcontainer/nsenter/nsexec.c @@ -364,6 +364,12 @@ void nsexec(void) return; } + /* make the process non-dumpable */ + if (prctl(PR_SET_DUMPABLE, 0, 0, 0, 0) != 0) { + pr_perror("Failed to set process as non-dumpable"); + exit(1); + } + // Retrieve the netlink header struct nlmsghdr nl_msg_hdr; int len;
Bug#850951: [pkg-go] Bug#850951: Bug#850951: CVE-2016-9962
On 30 January 2017 at 11:31, Salvatore Bonaccorsowrote: > Disclaimer: I'm not too deep into that. I just noticed that > https://bugzilla.novell.com/show_bug.cgi?id=1012568 though seem to > indicate as well 0.1.1 based version are affected. But I cannot tell > more (at the moment). Reading more into the vuln itself, I think ignoring the "stateDirFD" bits of the upstream patch is appropriate (and simply adding the "PR_SET_DUMPABLE" bit for "runc exec" as in "libcontainer/nsenter/nsexec.c"). I'm preparing a patch for the package now, but I'm curious what the implications of an upload will be so close to the freeze -- do we need to request a freeze exception or a migration adjustment after the updated package is up? Should I hold off on uploading? (would rather not lose "runc" from stretch) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#852751: Fix buggy encfs behavior
I agree with fixing the buggy behavior in encfs. I created an encfs paranoid folder and use cryptkeeper to open it without issues in Stretch. If someone creates one through cryptkeeper they will discover the problem quickly. That being said, I agree having a program with known bad behavior (cryptkeeper) is not preferred but the cause appears to come from another application. Tony
Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Hi! On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote: > Package: dpkg > Version: 1.18.21 > Severity: serious > X-Debbugs-CC: debian-...@lists.debian.org > [Disclaimer: I'm not an ARM porter and I don't really know much about > the ARM psABI] > > The new ABI mismatch detector seems to be a bit too strict on armel and > armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and > ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its > user but checking ABI comparability doesn't seem that simple. Indeed. :( > For example, on armel linking against libgsm.so currently gives this: > > $ dpkg-shlibdeps -v -e../a.out -Ttest > dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field) > dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, > libabi=0x010100280500 != objabi=0x0101002805000200 > dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out > (ELF format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '') > dpkg-shlibdeps: debug: Library libc.so.6 found in > /lib/arm-linux-gnueabi/libc.so.6 > dpkg-shlibdeps: debug: Using symbols file > /var/lib/dpkg/info/libc6:armel.symbols for libc.so.6 > dpkg-shlibdeps: warning: binaries to analyze should already be installed in > their package's directory > dpkg-shlibdeps: error: cannot continue due to the error above > Note: libraries are not searched in other binary packages that do not have > any shlibs or symbols file. > To help dpkg-shlibdeps find private libraries, you might need to use -l. > > Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to > generate a library which does not link against libc (this is used by > sonames2elf in some packages) causes both flags to be set (maybe > because it's compatible with both?). Even worse, I've found at least one instance of a package containing binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have to remove the flags matching on EM_ARM ELF binaries for now. At least this will get us back to the previous behavior with objdump, no regression in that sense. To be able to distinguish armel from armhf I'd probably need to check the arm attributes section for Tag_ABI_VFP_args, which annoyingly seems to be set even when the HARD flag is not set. :/ But this will be for dpkg 1.19.x. > This was first seen with wine: > https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0 > https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0 > > But there seem to be some other recent build failures relating to this > as well. Oh, wow, I'm not sure this is very kosher, but if it is causing build failures, then it does not matter much. I'm preparing an upload right now. Thanks, Guillem
Bug#853809: unblock: e2fsprogs/1.43.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package e2fsprogs 1.43.4 is the new upstream version of e2fsprogs which fixes a RC bug (#840733: e2fsprogs contains non-free file). n.b., the non-free file is only used in a regression test and isn't actually included in any binary. There are also a number of important bug fixes that I'd really like to get into stretch. See the debian changelog or [1] for more details. [1] http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43.4 Note: there is a udeb involved since this will also require a d-i release manager unblock. I'm unclear whether there is a separate process for requesting that particlar unblock. Please advise. I just uploaded 1.43.4-2 to sid today, so it will be five days old when the Stretch Freeze hits. So I'm filing this bug now as a heads up, since unless the release schedule slips, this isn't going to meet the mandatory 10 day delay which was announced in December. Files in second .deb but not in first - -rw-r--r-- root/root /usr/share/locale/fi/LC_MESSAGES/e2fsprogs.mo -rw-r--r-- root/root /usr/share/locale/ms/LC_MESSAGES/e2fsprogs.mo Files in first .deb but not in second - lrwxrwxrwx root/root /sbin/fsck.ext4dev -> e2fsck lrwxrwxrwx root/root /sbin/mkfs.ext4dev -> mke2fs lrwxrwxrwx root/root /usr/share/man/man8/fsck.ext4dev.8.gz -> e2fsck.8.gz lrwxrwxrwx root/root /usr/share/man/man8/mkfs.ext4dev.8.gz -> mke2fs.8.gz Control files: lines which differ (wdiff format) Installed-Size: [-3851-] {+4022+} Pre-Depends: e2fslibs (= [-1.43.3-1),-] {+1.43.4-2),+} libblkid1 (>= 2.17.2), libc6 (>= 2.14), libcomerr2 (>= 1.42~WIP-2011-10-05-1), libss2 (>= 1.34-1), libuuid1 (>= 2.16), util-linux (>= 2.15~rc1-1) Version: [-1.43.3-1-] {+1.43.4-2+} unblock e2fsprogs/1.43.4-2 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (650, 'testing'), (600, 'unstable-debug'), (600, 'unstable'), (500, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-00090-g3a45c5c (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#853808: unblock: ora2pg/18.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package ora2pg Hello, I've uploaded a new version of ora2pg to experimental, it is a new upstream release which allows us to ship it as part of main instead of contrib as it no longer depends on Oracle libraries It has the same dependencies as the previous version, 17.6-1 already on sid thanks unblock ora2pg/18.0-1 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-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)
Bug#853787: wxmaxima: loadfile: failed to load /usr/share/wxMaxima/wxmathml.lisp
What is the exact error message you get? My hope is that wxMaxima might have mentioned the line number it runs into an error in. -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Bug#853751: [Pkg-dns-devel] Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations
Steven Chamberlain wrote: > Hi, > > This bug has become important, since src:unbound became part of the > build-essential closure (due to Build-Depends of gnutls28). So this is > now a blocking issue for rebootstrapping kfreebsd and hurd. Hi, Steven: Thanks for this patch. Is this needed before stretch releases? (IIUC, kfreebsd and hurd are not release architectures?) > You could perhaps use libbsd unconditionally - on linux arches too - and > then the copy in compat/ would no longer be used. > > There is a long history of software embedding copies of arc4random, and > then forgetting to maintain them. There is a longer discussion of that > here: https://wiki.debian.org/arc4random > > I hold the opinion that packages should use the libbsd implementation > whereever possible, and then in Debian we would only need to maintain it > in one place, to the benefit of all reverse-deps. I agree with this reasoning, but I'd rather have the libbsd support in an upstream Unbound release rather than in the Debian package. I'll see about producing a patch suitable for upstream. -- Robert Edmonds edmo...@debian.org
Bug#853805: unknown-horizons: Use .png icons instead of .xpm
From 8bf142da177acc287e4d5e5f53c26ee3cf074a60 Mon Sep 17 00:00:00 2001 From: Jeremy BichaDate: Tue, 31 Jan 2017 19:47:24 -0500 Subject: [PATCH] Use .png app icons instead of obsolete .xpm, Drop Debian menu Closes: #853805 --- debian/control | 2 +- debian/install | 1 - debian/menu| 6 -- debian/rules | 14 +++--- 4 files changed, 12 insertions(+), 11 deletions(-) delete mode 100644 debian/install delete mode 100644 debian/menu diff --git a/debian/control b/debian/control index ad0bbd3..59cfb9d 100644 --- a/debian/control +++ b/debian/control @@ -9,7 +9,7 @@ Build-Depends: dh-python, docbook-xml, docbook-xsl, - imagemagick, + icnsutils, intltool, python, xsltproc diff --git a/debian/install b/debian/install deleted file mode 100644 index 6870a45..000 --- a/debian/install +++ /dev/null @@ -1 +0,0 @@ -unknown-horizons-32x32.xpm usr/share/pixmaps diff --git a/debian/menu b/debian/menu deleted file mode 100644 index 8075772..000 --- a/debian/menu +++ /dev/null @@ -1,6 +0,0 @@ -?package(unknown-horizons):needs="X11" \ - section="Games/Strategy" \ - title="Unknown Horizons" \ - longtitle="Unknown Horizons - 2D realtime strategy simulation" \ - command="/usr/games/unknown-horizons" \ - icon="/usr/share/pixmaps/unknown-horizons-32x32.xpm" diff --git a/debian/rules b/debian/rules index a43bf83..27f2862 100755 --- a/debian/rules +++ b/debian/rules @@ -14,9 +14,17 @@ override_dh_auto_install: debian/unknown-horizons/usr/share/unknown-horizons/content/fonts/OFL # Remove executable bit from files like tm_* and make Lintian happy find debian/unknown-horizons/usr/share/unknown-horizons -type f -exec chmod a-x {} \; - -override_dh_auto_build-indep: - convert -monitor -resize 32x32 $(CURDIR)/content/packages/unknown-horizons.xpm $(CURDIR)/unknown-horizons-32x32.xpm + mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/16x16/apps + mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/32x32/apps + mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/128x128/apps + mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/256x256/apps + mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/512x512/apps + icns2png -x ${CURDIR}/content/gui/icons/Icon.icns -o ${CURDIR} + mv ${CURDIR}/Icon_16x16x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/16x16/apps/unknown-horizons.png + mv ${CURDIR}/Icon_32x32x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/32x32/apps/unknown-horizons.png + mv ${CURDIR}/Icon_128x128x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/128x128/apps/unknown-horizons.png + mv ${CURDIR}/Icon_256x256x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/256x256/apps/unknown-horizons.png + mv ${CURDIR}/Icon_512x512x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/512x512/apps/unknown-horizons.png get-orig-source: uscan --force-download --download-current-version --repack --compression xz -- 2.10.2
Bug#828482: bug 828482 fix
Hi Sebastian, I am pretty sure that 4.11.3+dfsg-1 is not influenced by 828482 (FTBFS with openssl 1.1.0). Please send us the build log showing the issue you report. Thanks, Di-Shi Sun. -Original Message- From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc] Sent: Wednesday, February 01, 2017 4:43 AM To: Di-Shi Sun Cc: 828...@bugs.debian.org Subject: Re: bug 828482 fix On 2016-10-27 08:56:23 [+0800], Di-Shi Sun wrote: > osptoolkit/3.4.2-1.2 is out of date and osptoolkit/4.11.3+dfsg-1 has > been released to replace it. so what? 4.11.3+dfsg-1 is still affected by this problem. > Regards, > > > > Di-Shi Sun > VoIP Routing, Accounting, Security Sebastian
Bug#853807: -d stuck at end of -v in man page
Package: hydra Version: 8.3-2 Severity: minor File: /usr/share/man/man1/hydra.1.gz -v / -V verbose mode / show login+pass combination for each attempt -d debug mode
Bug#853806: ITP: golang-github-mrunalp-fileutils -- collection of utilities for file manipulation in golang
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-mrunalp-fileutils Version : 0.0~git20160930.0.4ee1cc9-1 Upstream Author : Mrunal Patel * URL : https://github.com/mrunalp/fileutils * License : Apache-2.0 Programming Lang: Go Description : Collection of utilities for file manipulation in golang This package is a collection of utilities for file manipulation in Go. . The library is based on the interface implemented by the Docker pkg/archive and pkg/idtools modules but does copies instead of handling archive formats. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853805: unknown-horizons: Use .png icons instead of .xpm
Package: unknown-horizons Version: 2017.1+ds-2 Tags: patch unknown-horizons does not show up in the GNOME Software app in Ubuntu but it does show up in Debian. This is because the appstream-generator used by Ubuntu is a bit older and rejects all .xpm icons. http://appstream.ubuntu.com/zesty/universe/issues/unknown-horizons.html https://appstream.debian.org/sid/main/issues/unknown-horizons.html The fix is pretty simple: use .png icons and do not ship a .xpm icon. The higher resolution icons look better anyway. I did see one difference. The .xpm has a banner that says Unknown Horizons but the .png's don't. I think the clearer icon in an interface like GNOME Shell's Activities Overview is more important than that banner. In my next email I'll attach a patch for this. There's also a patch to drop the Debian menu because it's obsolete if your package has a .desktop. https://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus Thanks, Jeremy Bicha
Bug#853802: FTBFS on armhf: cannot find library libmad.so.0
On Wed, Feb 01, 2017 at 02:34:04AM +0100, Rene Engelhard wrote: > Sounds like #853793. Actually, not sure. Shouldn't have writen this in my current tired state. Regards, Rene
Bug#853802: FTBFS on armhf: cannot find library libmad.so.0
Hi, [ not the maintainer ] On Wed, Feb 01, 2017 at 02:23:34AM +0100, Adam Borowski wrote: [...] >dh_shlibdeps > dpkg-shlibdeps: error: cannot find library libmad.so.0 needed by > debian/sonic-visualiser/usr/bin/sonic-visualiser (ELF format: > 'elf32-littlearm' abi: '0101002805000400'; RPATH: '') > dpkg-shlibdeps: warning: tried to merge the same object (ld-linux-armhf.so.3) > twice in a symfile > dpkg-shlibdeps: error: cannot continue due to the error above > Note: libraries are not searched in other binary packages that do not have > any shlibs or symbols file. > To help dpkg-shlibdeps find private libraries, you might need to use -l. > dh_shlibdeps: dpkg-shlibdeps -Tdebian/sonic-visualiser.substvars > debian/sonic-visualiser/usr/bin/sonic-visualiser returned exit code 2 > debian/rules:18: recipe for target 'binary' failed Sounds like #853793. Regards, Rene
Bug#853804: ITP: golang-github-bshuster-repo-logrus-logstash-hook -- Logstash hook for logrus
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-bshuster-repo-logrus-logstash-hook Version : 0.0~git20170102.0.5f729f2-1 Upstream Author : Boaz Shuster * URL : https://github.com/bshuster-repo/logrus-logstash-hook * License : Expat Programming Lang: Go Description : Logstash hook for Logrus logging library for Go Logrus is a structured logger for Go (golang), completely API compatible with the standard library logger. . This package is a hook to enable messages logged by Logrus to be sent to a Logstash instance. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853803: Please add a bzip2.pc pkg-config file
Package: libbz2-dev Unfortunately upstream bzip2 does not provide a pkg-config file for libbz2, which people who like pkg-config could use when compiling their software against libbz2. For example, Fedora adds such a file, which they have called bzip2.pc, themselves in their RPM package: see https://bugzilla.redhat.com/show_bug.cgi?id=1289576 Someone notes here that they made a similar request to upstream in December 2015, but apparently without a response: https://github.com/libimobiledevice/sbmanager/issues/1#issuecomment-163919580 Please consider adding a local patch so that the Debian libbz2-dev package also provides a pkg-config file, bzip2.pc. Thanks, John -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Bug#853801: qjoypad: segfaults on left click
Package: qjoypad Version: 4.1.0-2 Severity: important Left-clicking on the systray icon (or on the main window with --notray) immediately triggers a segfault: #0 0x5616b57ba023 in QBasicAtomicInt::deref() (this=0x7ffd) at /usr/include/qt4/QtCore/qatomic_x86_64.h:133 #1 0x5616b57ba023 in QString::~QString() (this=0x7ffd91e48d50, __in_chrg=) at /usr/include/qt4/QtCore/qstring.h:880 #2 0x5616b57ba023 in LayoutEdit::LayoutEdit(LayoutManager*) (this=0x5616b67266f0, l=) at layout_edit.cpp:50 #3 0x5616b57b4240 in LayoutManager::iconClick() (this=0x5616b670b330) at layout.cpp:258 #4 0x7fa25a512660 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=0x5616b6708dc0, m=m@entry=0x7fa25b546720 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffd91e48f00) at kernel/qobject.cpp:3567 #5 0x7fa25b0d258e in QSystemTrayIcon::activated(QSystemTrayIcon::ActivationReason) (this=, _t1=, _t1@entry=QSystemTrayIcon::Trigger) at .moc/release-shared/moc_qsystemtrayicon.cpp:147 #6 0x7fa25b09d335 in qtsystray_sendActivated(QSystemTrayIcon*, int) (i=, r=r@entry=3) at util/qsystemtrayicon.cpp:663 #7 0x7fa25b0b351e in QSystemTrayIconWidget::mousePressEvent(QMouseEvent*) (this=0x5616b671e260, ev=0x7ffd91e493f0) at util/qxembedsystemtrayicon_x11.cpp:202 #8 0x7fa25aa81a40 in QWidget::event(QEvent*) (this=0x5616b671e260, event=0x7ffd91e493f0) at kernel/qwidget.cpp:8385 #9 0x7fa25aa2a54c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x5616b669d110, receiver=receiver@entry=0x5616b671e260, e=e@entry=0x7ffd91e493f0) at kernel/qapplication.cpp:4570 #10 0x7fa25aa32ca7 in QApplication::notify(QObject*, QEvent*) (this=, receiver=0x5616b671e260, e=0x7ffd91e493f0) at kernel/qapplication.cpp:4113 #11 0x7fa25a4fdf1d in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7ffd91e49c60, receiver=receiver@entry=0x5616b671e260, event=event@entry=0x7ffd91e493f0) at kernel/qcoreapplication.cpp:955 #12 0x7fa25aa30ccb in QCoreApplication::sendEvent(QObject*, QEvent*) (event=, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #13 0x7fa25aa30ccb in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) (receiver=receiver@entry=0x5616b671e260, event=event@entry=0x7ffd91e493f0, alienWidget=alienWidget@entry=0x0, nativeWidget=nativeWidget@entry=0x5616b671e260, buttonDown=buttonDown@entry=0x7fa25b550348 , lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:3178 #14 0x7fa25aaac1a9 in QETWidget::translateMouseEvent(_XEvent const*) (this=this@entry=0x5616b671e260, event=event@entry=0x7ffd91e49750) at kernel/qapplication_x11.cpp:4557 #15 0x7fa25b5c in QApplication::x11ProcessEvent(_XEvent*) (this=0x7ffd91e49c60, event=event@entry=0x7ffd91e49750) at kernel/qapplication_x11.cpp:3674 #16 0x7fa25aad4502 in x11EventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x5616b669f920, callback=0x0, user_data=0x0) at kernel/qguieventdispatcher_glib.cpp:146 #17 0x7fa2585ab7f7 in g_main_dispatch (context=0x5616b669e5a0) at ././glib/gmain.c:3203 #18 0x7fa2585ab7f7 in g_main_context_dispatch (context=context@entry=0x5616b669e5a0) at ././glib/gmain.c:3856 #19 0x7fa2585aba60 in g_main_context_iterate (context=context@entry=0x5616b669e5a0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929 #20 0x7fa2585abb0c in g_main_context_iteration (context=0x5616b669e5a0, may_block=may_block@entry=1) at ././glib/gmain.c:3990 #21 0x7fa25a52e854 in QEventDispatcherGlib::processEvents(QFlags) (this=0x5616b669e460, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #22 0x7fa25aad45d6 in QGuiEventDispatcherGlib::processEvents(QFlags) (this=, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #23 0x7fa25a4fc7ef in QEventLoop::processEvents(QFlags) (this=this@entry=0x7ffd91e49b30, flags=...) at kernel/qeventloop.cpp:149 #24 0x7fa25a4fcb55 in QEventLoop::exec(QFlags) (this=this@entry=0x7ffd91e49b30, flags=...) at kernel/qeventloop.cpp:204 #25 0x7fa25a502bd9 in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1227 #26 0x5616b57a716a in main(int, char**) (argc=, argv=) at main.cpp:216 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/3 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages qjoypad depends on: ii libc6 2.24-9 ii libgcc1 1:6.3.0-5 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libstdc++6 6.3.0-5 ii libx11-62:1.6.4-3 ii libxtst6
Bug#853800: 2048-qt: Does not show up in GNOME Software app
From 182effecf3cdd42fe9bde07d88144ec71f5974c6 Mon Sep 17 00:00:00 2001 From: Jeremy BichaDate: Tue, 31 Jan 2017 19:40:19 -0500 Subject: [PATCH 1/2] Use .png icons instead of obsolete .xpm Closes: #853800 --- debian/2048-qt.install | 3 +- debian/2048-qt.xpm | 128 - 2 files changed, 2 insertions(+), 129 deletions(-) delete mode 100644 debian/2048-qt.xpm diff --git a/debian/2048-qt.install b/debian/2048-qt.install index 7035daf..8c96930 100644 --- a/debian/2048-qt.install +++ b/debian/2048-qt.install @@ -1,2 +1,3 @@ -debian/2048-qt.xpm /usr/share/pixmaps res/2048-qt.desktop /usr/share/applications/ +res/icons/*x* /usr/share/icons/hicolor +res/icons/scalable /usr/share/icons/hicolor diff --git a/debian/2048-qt.xpm b/debian/2048-qt.xpm deleted file mode 100644 index 521aeb7..000 --- a/debian/2048-qt.xpm +++ /dev/null @@ -1,128 +0,0 @@ -/* XPM */ -static char *_048_qt[] = { -/* columns rows colors chars-per-pixel */ -"32 32 90 1 ", -" c #EDC22D", -". c #EDC22E", -"X c #EDC330", -"o c #EDC433", -"O c #EDC435", -"+ c #EEC539", -"@ c #EEC63C", -"# c #EEC63D", -"$ c #80C242", -"% c #80C342", -"& c #83C547", -"* c #84C548", -"= c #87C74D", -"- c #8BC852", -"; c #8DC956", -": c #95CD62", -"> c #98CE66", -", c #99CF68", -"< c #9DD16E", -"1 c #A2D374", -"2 c #A6D57B", -"3 c #EEC843", -"4 c #EFC946", -"5 c #EFC948", -"6 c #EFCB4F", -"7 c #EFCC53", -"8 c #EFCD56", -"9 c #F0CE5A", -"0 c #F0CF5E", -"q c #F0D061", -"w c #F0D062", -"e c #F0D064", -"r c #F1D36C", -"t c #F1D473", -"y c #F1D573", -"u c #F1D576", -"i c #F2D679", -"p c #F2D77E", -"a c #AAD781", -"s c #AED986", -"d c #B7DD94", -"f c #B8DD95", -"g c #BEE09E", -"h c #F3DA87", -"j c #F3DA88", -"k c #F3DA89", -"l c #F3DB8C", -"z c #F3DC91", -"x c #F3DD95", -"c c #F4DF9B", -"v c #C0E1A1", -"b c #C6E4AA", -"n c #C8E5AD", -"m c #F4E0A0", -"M c #F4E2A6", -"N c #F5E3AB", -"B c #F5E4AC", -"V c #F5E5B3", -"C c #F5E6B7", -"Z c #F5E7B7", -"A c #F6E7BA", -"S c #F6E9BF", -"D c #D5EBC0", -"F c #D6ECC2", -"G c #D7ECC4", -"H c #D8EDC5", -"J c #DCEECA", -"K c #DFF0CF", -"L c #F6E9C2", -"P c #F6EAC4", -"I c #F6EAC6", -"U c #F6EBC8", -"Y c #F7ECCB", -"T c #F7ECCE", -"R c #F7EDD1", -"E c #F7EFD8", -"W c #F7EFD9", -"Q c #E2F1D3", -"! c #E3F2D5", -"~ c #E6F3D9", -"^ c #F8F0DA", -"/ c #F8F1DF", -"( c #ECF6E2", -") c #EDF7E4", -"_ c #F8F1E0", -"` c #F9F5ED", -"' c #F0F8E9", -"] c #F4FAEE", -"[ c #F7FBF2", -"{ c #FBFDF8", -/* pixels */ -"", -"", -"", -"", -"XhPN8 0LPqhz qCC0 ", -"@x50R o/rq_+ 8YB OE@3Ro", -"_OeP St oPtB +_OoEO", -" eC pM ck cueB pTPr ", -" 3R3 pm xl0B qB BmLx ", -" +Uq rS CiTABLElqC S9", -"OLr @/+@/4800kL79C A6", -"p`^^Wu h//keB mSLz ", -"", -"", -"", -"", -"", -"", -"", -"%%%~!f%%%-", -"%%%KH,1!v%%K", -"%%:{*%%:{*n{J1%%", -"%%aQ%%$$]>*'", -"%%sG%%$$)>&'", -"%%<[%%$;{&&'", -"%%%(d&=nD%%'", -"%%%:!'{G&%%n!2%%", -"%~*%%%*%%%", -"%", -"&%%%", -"", -"" -}; -- 2.10.2 From c8533b374f2888e1d45f60cd97ed73a54d616dea Mon Sep 17 00:00:00 2001 From: Jeremy Bicha Date: Tue, 31 Jan 2017 19:51:56 -0500 Subject: [PATCH 2/2] Drop obsolete Debian menu --- debian/2048-qt.menu | 4 1 file changed, 4 deletions(-) delete mode 100644 debian/2048-qt.menu diff --git a/debian/2048-qt.menu b/debian/2048-qt.menu deleted file mode 100644 index db966ef..000 --- a/debian/2048-qt.menu +++ /dev/null @@ -1,4 +0,0 @@ -?package(2048-qt):needs="X11" section="Games/Puzzles" \ - title="2048-qt" command="/usr/games/2048-qt" \ - icon="/usr/share/pixmaps/2048-qt.xpm" \ - longtitle="2048-qt: mathematics based puzzle game" -- 2.10.2
Bug#853800: 2048-qt: Does not show up in GNOME Software app
Package: 2048-qt Version: 0.1.6-1 Tags: patch 2048-qt does not show up in the GNOME Software app. This app will be included in the GNOME version of the next stable Debian release. I don't use KDE but maybe this affects their app installer too. https://appstream.debian.org/sid/main/issues/2048-qt.html The fix is pretty simple: use .png icons and do not ship a .xpm icon. (I think shipping a .xpm icon will upset the appstream generator). In my next email I'll attach a patch for this. There's also a patch to drop the Debian menu because it's obsolete if your package has a .desktop. https://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus Thanks, Jeremy Bicha
Bug#853107: xapian-core: FTBFS under pbuilder with USENETWORK=no
On Tue, Jan 31, 2017 at 10:09:57PM +0100, Georg Faerber wrote: > > Daniel: What version of pbuilder are you using? If it's more than a > > year old, then upgrading will probably fix this. If not, then either > > that fix has regressed in pbuilder regression, or else something more > > complex is going on. > > This is happening here [1] as well, which is a recent pbuilder version, > I guess. I'm wondering if this is a bug in pbuilder or a wrapper around. > > Cheers, > Georg > (who debugged for some hours a similar problem over here [2]...) Did you reach any useful conclusions? FWIW, the code that appears to fail is: struct addrinfo hints; memset(, 0, sizeof(struct addrinfo)); hints.ai_family = AF_INET; hints.ai_socktype = SOCK_STREAM; hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_NUMERICSERV; hints.ai_protocol = 0; hints.ai_canonname = NULL; hints.ai_addr = NULL; hints.ai_next = NULL; const char * node = host.empty() ? NULL : host.c_str(); struct addrinfo *result; int s = getaddrinfo(node, str(port).c_str(), , ); if (s != 0) { throw Xapian::NetworkError("Couldn't resolve host " + host, eai_to_xapian(s)); } Where host is "127.0.0.1" and port is "1239". It seems the error is: EAI_NONAME The node or service is not known; or both node and service are NULL; or AI_NUMERICSERV was specified in hints.ai_flags and ser‐ vice was not a numeric port-number string. The reproducible build used to work but it looks like it regressed in 1.3.4-1: https://tests.reproducible-builds.org/debian/history/xapian-core.html That's very suspicious as that's the first version packaged for Debian which used getaddrinfo() (1.2.x used gethostbyname(), etc), and the history shows that 1.2.x continued to build OK at the same time. So that seems to point firmly to this not being a pbuilder regression. But I've no idea what the cause is. My only thoughts are that perhaps there's only IPv6 loopback (but then 1.2.x wouldn't work), or that getaddrinfo() is interacting badly with the restricted networking. Cheers, Olly
Bug#604754: Sehr geehrter E-Mail-Benutzer
Sehr geehrter E-Mail-Benutzer Bitte folgen Sie dem Link, um Ihr Webmail-Konto zu aktualisieren: http://0sptfn211.ukit.me Vielen Dank
Bug#853799: Please update to stable libevent 2.1 series
Source: libevent Version: 2.1.4~alpha-0.1+b1 Severity: wishlist Version 2.1.8-stable has been released a couple of days ago on libevent.org and I guess it's time to update this rotten package in Experimental. Regards, Eduard. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- Religionen haben Mord und Selbstmord verurteilt, haben aber, vom Menschenopfer ganz abgesehen, grausamste Verfolgungen Andersgläubiger erlaubt oder geboten. -- Fritz Max Bauer
Bug#841185: closing RFS: genwqe-user/4.0.18-1 [ITP #826774]
On Tue, 31 Jan 2017 22:20:44 + Bart Martenswrote: > Package genwqe-user has been removed from mentors. > > Sorry, I had deleted and re-uploaded it but had problems with the queue, which was solved. I fixed some problems with the package, that is why I reopened this RFS. It can be checked out at: dget -x https://mentors.debian.net/debian/pool/contrib/g/genwqe-user/genwqe-user_4.0.18-1.dsc Thanks! -- Fernando Seiti Furusato IBM Linux Technology Center signature.asc Description: OpenPGP digital signature
Bug#852398: To load extensions
Copying this over from #851692. A method of enabling extensions without re-compiling Chromium. Not saying it is ideal 1. Find your extensions: They are in $XDG_CONFIG_DIR/chromium//Extensions// For example, uBlock is at /home/alok/.config/chromium/Default/Extensions/cjpalhdlnbpafiamejdnhcphjbkeiagm/1.9.4_0 2. Create a file in /etc/chromium.d/enable-extensions with the content export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --load-extension=" 3. You have to create multiple lines of the form above for each profile. Note that you will have to update this file when the extension version changes. If you have the same extension in multiple profiles, you will have make explicit entries for it as per step 2. -- — Alok
Bug#853798: mpv: Segfaults on TV input
Package: mpv Version: 0.23.0-1 Severity: important mpv quickly segfaults (before displaying any video) on TV input: $ mpv tv:// Playing: tv:// [tv] Selected driver: v4l2 [tv] name: Video 4 Linux 2 input [tv] Selected device: BT878 video (Hauppauge (bt878)) [tv] Tuner cap: [tv] Tuner rxs: MONO [tv] Capabilities: video capture video overlay VBI capture device tuner read/write streaming [tv] supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = PAL; 5 = PAL-BG; 6 = PAL-H; 7 = PAL-I; 8 = PAL-DK; 9 = PAL-M; 10 = PAL-N; 11 = PAL-Nc; 12 = PAL-60; 13 = SECAM; 14 = SECAM-B; 15 = SECAM-G; 16 = SECAM-H; 17 = SECAM-DK; 18 = SECAM-L; 19 = SECAM-Lc; [tv] inputs: 0 = Television; 1 = Composite1; 2 = S-Video; 3 = Composite3; [tv] Current input: 0 [tv] Current format: YVU420 [tv] current audio mode is : MONO Segmentation fault For what it's worth, this bug does not seem to be present in MPlayer. Backtrace follows. Let me know if I can be of any further help. #0 0x557aee3e8dc7 in set_norm_and_freq (tvh=tvh@entry=0x7f397001e700, chan=0x5a0005) at ../stream/tv.c:430 #1 0x557aee3e94d6 in open_tv (tvh=tvh@entry=0x7f397001e700) at ../stream/tv.c:599 #2 0x557aee3950e4 in demux_open_tv (demuxer=0x7f3970007590, check=) at ../demux/demux_tv.c:52 #3 0x557aee383ab3 in open_given_type (global=global@entry=0x557aef6fc2b0, log=log@entry=0x7f39700035b0, desc=0x557aee6bf4c0 , stream=stream@entry=0x7f39805fc050, params=params@entry=0x7f397bffea50, check=check@entry=DEMUX_CHECK_REQUEST) at ../demux/demux.c:1274 #4 0x557aee383ef7 in demux_open (stream=0x7f39805fc050, params=params@entry=0x7f397bffea50, global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1354 #5 0x557aee3840b6 in demux_open_url (url=, params=params@entry=0x7f397bffea50, cancel=, global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1393 #6 0x557aee3c5155 in open_demux_thread (pctx=0x7ffc0dd234f0) at ../player/loadfile.c:797 #7 0x557aee3c8ca0 in thread_wrapper (pctx=0x7ffc0dd23460) at ../player/misc.c:267 #8 0x7f39a996b424 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x7f39a4aa19bf in clone () from /lib/x86_64-linux-gnu/libc.so.6 #0 0x557aee3e8dc7 in set_norm_and_freq (tvh=tvh@entry=0x7f397001e700, chan=0x5a0005) at ../stream/tv.c:430 #1 0x557aee3e94d6 in open_tv (tvh=tvh@entry=0x7f397001e700) at ../stream/tv.c:599 #2 0x557aee3950e4 in demux_open_tv (demuxer=0x7f3970007590, check=) at ../demux/demux_tv.c:52 #3 0x557aee383ab3 in open_given_type (global=global@entry=0x557aef6fc2b0, log=log@entry=0x7f39700035b0, desc=0x557aee6bf4c0 , stream=stream@entry=0x7f39805fc050, params=params@entry=0x7f397bffea50, check=check@entry=DEMUX_CHECK_REQUEST) at ../demux/demux.c:1274 #4 0x557aee383ef7 in demux_open (stream=0x7f39805fc050, params=params@entry=0x7f397bffea50, global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1354 #5 0x557aee3840b6 in demux_open_url (url=, params=params@entry=0x7f397bffea50, cancel=, global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1393 #6 0x557aee3c5155 in open_demux_thread (pctx=0x7ffc0dd234f0) at ../player/loadfile.c:797 #7 0x557aee3c8ca0 in thread_wrapper (pctx=0x7ffc0dd23460) at ../player/misc.c:267 #8 0x7f39a996b424 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x7f39a4aa19bf in clone () from /lib/x86_64-linux-gnu/libc.so.6 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/3 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mpv depends on: ii libasound2 1.1.3-4 ii libass5 1:0.13.4-2 ii libavcodec577:3.2.2-2 ii libavdevice57 7:3.2.2-2 ii libavfilter67:3.2.2-2 ii libavformat57 7:3.2.2-2 ii libavutil55 7:3.2.2-2 ii libbluray1 1:0.9.3-3 ii libc6 2.24-9 ii libcdio-cdda1 0.83-4.3 ii libcdio-paranoia1 0.83-4.3 ii libcdio13 0.83-4.3 ii libdrm2 2.4.74-1 ii libdvdnav4 5.0.3-3 ii libdvdread4 5.0.3-2 ii libegl1-mesa [libegl1-x11] 13.0.3-1 ii libgbm1 13.0.3-1 ii libgl1-mesa-glx [libgl1]13.0.3-1 ii libjack0 [libjack-0.125]
Bug#853797: xjdic: May crash on long definitions when looking up plain form verbs
Package: xjdic Version: 24-10 Severity: normal xjdic may trigger a buffer overflow on long definitions when looking up plain form verbs, which occurs when fed an inflected verb in kanji form: $ echo '出て' | xjdic [...] *** buffer overflow detected ***: xjdic terminated [...] Aborted The overflow happens in Vlookup(), at xjdfrontend.c, line 1155: vline is just too short, at 250 bytes, for some of the longest definitions. (出る seems to be the most extreme case, at 1129 bytes.) -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/3 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xjdic depends on: pn edict:all pn kanjidic:all ii libc6 2.24-9 Versions of packages xjdic recommends: ii kterm 6.2.0-46.2 xjdic suggests no packages. -- no debconf information
Bug#853775: a confirmation the newer pango helped
I may confirm that this workflow helped: $ apt-get source libpango1.0-0/testing $ cd pango1.0-1.40.3 $ # solve the dependency on newer version of libthai $ dpkg-buildpackage -b -uc -d # "-d" because of the dependency on debhelper>=10 $ sudo dpkg -i ~user/{libpango,gir}*.deb # needed BEFORE building inkscape package! $ cd ; apt-get source inkscape/jessie-backports $ cd inkscape-0.92.0 $ vim debian/control # fix the dependency on libpango1.0 >= 1.37.1 $ dpkg-buildpackage -b -uc -d # again, "-d" because of the dependency on debhelper>=10 $ # make a coffee or buy a faster machine than I have $ sudo dpkg -i ~user/inkscape*.deb $ # be happy with the test document, for example font features work now
Bug#853467: goldencheetah: Upload new version to support Garmin CIQ developer fields
hi, On Tue, Jan 31, 2017 at 6:35 PM, Markus Braunwrote: > I'm using a Garmin watch as runner to track my workouts. Some days ago > I received a Stryd footpod to track running power. Running power is > recorded to the FIT file in an CIQ developer field. The current Debian > version of goldencheetah does not support the additional fields but the > current GIT version of goldencheetah does. The developers started adding > these in October 2016. The current official version on > www.goldencheetah.org does support my FIT files. But it is not possible > to install the Debian package on SID because of missing dependencies. I've uploaded GC4.0 series development build early 2016. For now, upstream seems to focus on making enhancement into GC3.0 series stable build, at least since August 2016. > Could you please provide a more current version of goldencheetah? I think that soon after upstrem releasing new 4.0 series build, I will update its packaging. https://github.com/GoldenCheetah/GoldenCheetah/releases regards, -- KURASHIKI Satoru
Bug#852924: collectd: FTBFS: ld: cannot find -lssl
control: reassign -1 collectd 5.7.1-1 control: retitle -1 Uses "-lssl -lcrypto" but does not depend on libssl On 2017-01-28 12:13:57 [+0100], Marc Fournier wrote: > On Sat, Jan 28, 2017 at 09:30:20AM +0100, Lucas Nussbaum wrote: > > During a rebuild of all packages in sid, your package failed to build on > > amd64. > > > > Relevant part (hopefully): > > > /bin/bash ../libtool --tag=CC --mode=link x86_64-linux-gnu-gcc -Wall > > > -Werror -g -O2 -fdebug-prefix-map=/<>=. > > > -fstack-protector-strong -Wformat -Werror=format-security -Wall > > > -Wno-error=deprecated-declarations -module -avoid-version > > > -export-symbols-regex '\' -Wl,-z,relro -o > > > notify_email.la -rpath /usr/lib/collectd notify_email.lo -lesmtp -lssl > > > -lcrypto > > > libtool: link: /usr/bin/x86_64-linux-gnu-nm -B .libs/notify_email.o | > > > sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ > > > ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | > > > /bin/sed 's/.* //' | sort | uniq > .libs/notify_email.exp > > > libtool: link: /bin/grep -E -e "\ " > > > ".libs/notify_email.exp" > ".libs/notify_email.expT" > > > libtool: link: mv -f ".libs/notify_email.expT" ".libs/notify_email.exp" > > > libtool: link: echo "{ global:" > .libs/notify_email.ver > > > libtool: link: cat .libs/notify_email.exp | sed -e "s/\(.*\)/\1;/" >> > > > .libs/notify_email.ver > > > libtool: link: echo "local: *; };" >> .libs/notify_email.ver > > > libtool: link: x86_64-linux-gnu-gcc -shared -fPIC -DPIC > > > .libs/notify_email.o -lesmtp -lssl -lcrypto -g -O2 > > > -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-soname > > > -Wl,notify_email.so -Wl,-version-script -Wl,.libs/notify_email.ver -o > > > .libs/notify_email.so > > > /usr/bin/ld: cannot find -lssl > > > /usr/bin/ld: cannot find -lcrypto > > > collect2: error: ld returned 1 exit status > > > > The full build log is available from: > >http://aws-logs.debian.net/2017/01/28/collectd_5.7.1-1_unstable.log > > Nice catch, thanks ! > > One thing that puzzles me, is why didn't this pop up earlier. collectd does > *not* build-depend on libssl-dev. But according to the latest build log[1] > libssl1.0-dev gets installed nevertheless (making this mistake in > collectd's Makefile work by accident). This is not the case on the > AWS-based builder. Okay. Unmerged, back. Earlier net-snmp's -dev package pulled in libssl-dev. This packages explicitly adds "-lssl -lcrypto" but does not need to link against any of those libs, it simply needs to link against -lesmtp for the email plugin. Therefore I unmerged the two bugs and am attaching the patch which strips the hardcoded libs. The result builds. Any testing and feedback is appreciated. > Cheers, > Marc Sebastian Author: Sebastian Andrzej Siewior Subject: Remove SSL libs from libs The Makefile/Configure adds "-lssl -lcrypto" but does not depend libssl-dev nor does it use any of its functions diretly. Depending on those should not be needed unless for static compilation thus removing them. --- configure.ac|2 +- src/Makefile.am |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/configure.ac +++ b/configure.ac @@ -3574,7 +3574,7 @@ then if test "x$LIBNETAPP_LIBS" = "x" then - LIBNETAPP_LIBS="$PTHREAD_LIBS -lxml -ladt -lssl -lm -lcrypto -lz" + LIBNETAPP_LIBS="$PTHREAD_LIBS -lxml -ladt -lm -lz" fi AC_MSG_NOTICE([netapp LIBS: $LIBNETAPP_LIBS]) --- a/src/Makefile.am +++ b/src/Makefile.am @@ -825,7 +825,7 @@ if BUILD_PLUGIN_NOTIFY_EMAIL pkglib_LTLIBRARIES += notify_email.la notify_email_la_SOURCES = notify_email.c notify_email_la_LDFLAGS = $(PLUGIN_LDFLAGS) -notify_email_la_LIBADD = -lesmtp -lssl -lcrypto +notify_email_la_LIBADD = -lesmtp endif if BUILD_PLUGIN_NOTIFY_NAGIOS
Bug#852884: libesmtp: diff for NMU version 1.0.6-4.2
Control: tags 852884 + patch Control: tags 852884 + pending Dear maintainer, I've prepared an NMU for libesmtp (versioned as 1.0.6-4.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. The following patches build with this change: - balsa_2.4.12-3_amd64 - cacti-spine_0.8.8h-3_amd64 - hplip_3.16.11+repack0-2_amd64 - pacemaker_1.1.16-1_amd64 - syslog-ng_3.8.1-9_amd64 collectd_5.7.1-1_amd64 fails but it has the -lssl -lcrypto hardcoded and I am going to supply a patch in #852924. Regards. diff -Nru libesmtp-1.0.6/debian/changelog libesmtp-1.0.6/debian/changelog --- libesmtp-1.0.6/debian/changelog 2016-11-18 23:28:19.0 +0100 +++ libesmtp-1.0.6/debian/changelog 2017-01-31 23:51:33.0 +0100 @@ -1,3 +1,10 @@ +libesmtp (1.0.6-4.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop "-lssl -lcrypto" from exported libs flags (Closes: #852884). + + -- Sebastian Andrzej SiewiorTue, 31 Jan 2017 23:51:33 +0100 + libesmtp (1.0.6-4.1) unstable; urgency=medium * Non-maintainer upload diff -Nru libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch --- libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch 1970-01-01 01:00:00.0 +0100 +++ libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch 2017-01-31 23:51:33.0 +0100 @@ -0,0 +1,24 @@ +Author: Sebastian Andrzej Siewior +Subject: Remove SSL libs from libs + +The config script returns "-lssl -lcrypto" but does not depend libssl-dev. +Depending on those should not be needed unless for static compilation thus +removing them. + +BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852884 + +--- + libesmtp-config.in |2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/libesmtp-config.in b/libesmtp-config.in +@@ -69,7 +69,7 @@ while test $# -gt 0; do + ;; + + --libs) +- echo @PTHREAD_LDFLAGS@ -L@libdir@ -lesmtp @LIBS@ @PTHREAD_LIBS@ ++ echo @PTHREAD_LDFLAGS@ -L@libdir@ -lesmtp @PTHREAD_LIBS@ + ;; + + --plugindir) diff -Nru libesmtp-1.0.6/debian/patches/series libesmtp-1.0.6/debian/patches/series --- libesmtp-1.0.6/debian/patches/series 2016-11-18 22:37:22.0 +0100 +++ libesmtp-1.0.6/debian/patches/series 2017-01-31 23:46:39.0 +0100 @@ -1,3 +1,4 @@ headers-c sys-types-h openssl +remove_ssl_libs_from_libs.patch
Bug#853776: Please provide deb.debian.org as an option
Control: clone -1 -2 Control: reassign -2 mirrors Control: retitle -2 Please add deb.debian.org to Mirrors.masterlist Control: block -1 by -2 On 31 Jan 2017, at 23:19, Cyril Bruleboiswrote: > James Clarke (2017-01-31): >> Package: choose-mirror >> Version: 2.74 >> Severity: wishlist >> >> As the title says; as far as I can tell, deb.debian.org is still not >> provided as an option during installation; instead, you have to enter it >> manually. Please add it alongside httpredir. > > We sync the Mirrors.masterlist file from mirrors: > > https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist?revision=HEAD > > so please get it added there (clone/reassign/block if you like), and let > us know once that's done so that we reupload choose-mirror. Done (assuming I didn't mess up my control commands); thanks. James
Bug#853776: Please provide deb.debian.org as an option
Hi, James Clarke(2017-01-31): > Package: choose-mirror > Version: 2.74 > Severity: wishlist > > As the title says; as far as I can tell, deb.debian.org is still not > provided as an option during installation; instead, you have to enter it > manually. Please add it alongside httpredir. We sync the Mirrors.masterlist file from mirrors: https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist?revision=HEAD so please get it added there (clone/reassign/block if you like), and let us know once that's done so that we reupload choose-mirror. KiBi. signature.asc Description: Digital signature
Bug#853277: os-prober: triggers hang on default install with unencrypted LVM
Control: tag -1 patch pending Hi, Cyril Brulebois(2017-01-31): > When picking plain LVM (not encrypted), os-prober 1.73 hangs right after > having printed this to syslog, with slight variations: > | 50mount-tests: debug: creating device mapper device > /dev/mapper/osprober-linux-sda3 [Steve] > | 50mount-tests: debug: creating device mapper device > /dev/mapper/osprober-linux-vda5 [Cyril] > > The issue seems to be the dmsetup create call (with -r and the partition > name) getting stuck in the kernel on the dm_ctl_ioctl call, possibly > because we're trying to play with something that's mounted already? > > Looking at commits touching dmsetup stuff, I went back to the first one > between 1.71 and 1.72: > | commit 8a8f565b43fd126e97b2c390bd81868c6653cf2c > | Author: Ivo De Decker > | Date: Sat Jul 13 21:15:41 2013 +0200 > | > | using read-only device mapper entry > > and using a version built from it is sufficient to reproduce the hang. Since that's basically the first time I'm touching os-prober, I first went for special-casing the partition holding the root filesystem, and tested an installation from a custom CD image successfully. Branch on alioth: kibi-vs-lvm; and patches: https://anonscm.debian.org/cgit/d-i/os-prober.git/commit/?id=16eae6151b713e4db2836b81e7958902544a5ecd https://anonscm.debian.org/cgit/d-i/os-prober.git/commit/?id=d70f8416d3555a772666e105d13589416e6e5c0e I wasn't too happy about it since there's a os-prober-udeb and lsblk isn't available in a debian-installer context (it's available in /target so it works properly for the use cases I had been testing). Ivo joined the party and proposed a different approach: excluding LVM2_member partitions (since they're physical volumes), and I liked this approach a lot more. Tests are looking fine so I went for it for 1.74. Thinking about other use cases, Ivo noted that we might want to exclude something else for which there's no codepath: linux_raid_member. But I think I'll leave that for a later revision of this package, and try to resume the D-I Stretch RC 2 release process with os-prober 1.74. The linux_raid_member thing can be filed as a separate bug report (feel free to; I'll be doing more testing). KiBi. signature.asc Description: Digital signature
Bug#853179: libgraphite2-dev: the -dev package is missing the .a library for static linkage
Quotation from Rene Engelhard at Januar 30, 2017 15:55: Not every upstream ships static libraries per default. So it is with graphite2. my assumption was that every -dev package provides it. sorry for that. And I am not going to "invent" it and patch around in the cmake (brrr...) agree. please close the report. thank you for your efforts on that. M. Dietrich pgp1j_om_z6K7.pgp Description: PGP signature
Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading
Wed, 1 Feb 2017 00:18:18 +0200 Otto Kekäläinenécrivait : > Thank you very much Jean-Marc for helping with testing! I helped with great pleasure. > > Can you please also try running apt-get purge mysql-* and see if it removes > the remnants cleanly? But not too cleanly, mysqld binary or /var/lib/mysql > used by mariadb-10.1 should not get deleted by the mysql purge (one user > reported he suffered such a case). So, after the dist-upgrade + autoremove --purge, I listed remaining packages containing mysql: $ dpkg --list | grep mysql ii default-mysql-client1.0.2 all MySQL database client binaries (metapackage) ii default-mysql-server1.0.2 all MySQL database server binaries and system database setup (metapackage) ii libdbd-mysql-perl 4.041-1 amd64 Perl5 database interface to the MariaDB/MySQL database ii mysql-common5.8+1.0.2 all MySQL database common files, e.g. /etc/mysql/my.cnf rc mysql-server-5.55.5.54-0+deb8u1 amd64 MySQL database server binaries and system database setup So, mysql-common 5.8+1.0.2 is still installed and mysql-server-5.5 is removed but Config files remain on the machine. And I simulated the purge you described: $ apt-get purge --simulate mysql-* [...] The following packages were automatically installed and are no longer required: galera-3 libaio1 libdbi-perl libjemalloc1 libreadline5 libterm-readkey-perl rsync socat Use 'apt autoremove' to remove them. The following packages will be REMOVED: default-mysql-client* default-mysql-server* libdbd-mysql-perl* libmariadbclient18* mariadb-client-10.1* mariadb-client-core-10.1* mariadb-common* mariadb-server-10.1* mariadb-server-core-10.1* mysql-common* mysql-server-5.5* 0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded. Purg default-mysql-client [1.0.2] Purg default-mysql-server [1.0.2] Purg libdbd-mysql-perl [4.041-1] Purg libmariadbclient18 [10.1.21-5] Purg mariadb-server-10.1 [10.1.21-5] Purg mariadb-client-10.1 [10.1.21-5] Purg mariadb-client-core-10.1 [10.1.21-5] Purg mariadb-server-core-10.1 [10.1.21-5] Purg mariadb-common [10.1.21-5] Purg mysql-common [5.8+1.0.2] Purg mysql-server-5.5 Apparently, it is too cleanly. :-) I think it comes from the dependency between mysql-common and mariadb: $ apt rdepends mysql-common mysql-common Reverse Depends: PreDepends: mysql-server-5.5 (>= 5.5.54-0+deb8u1) Depends: mariadb-common (>= 5.6.25) Depends: libmariadbclient18 So, I think you can purge mysql-server-5.5 without any problem but not mysql-common: $ apt purge --simulate mysql-server-5.5 [...] The following packages will be REMOVED: mysql-server-5.5* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Purg mysql-server-5.5 For your info, there is the files from mysql-server-5.5 remain on my VM: $ dpkg --listfiles mysql-server-5.5 /etc /etc/logrotate.d /etc/logcheck /etc/logcheck/ignore.d.paranoid /etc/logcheck/ignore.d.paranoid/mysql-server-5_5 /etc/logcheck/ignore.d.server /etc/logcheck/ignore.d.server/mysql-server-5_5 /etc/logcheck/ignore.d.workstation /etc/logcheck/ignore.d.workstation/mysql-server-5_5 /etc/init.d /etc/apparmor.d /etc/mysql /etc/mysql/conf.d /etc/mysql/conf.d/mysqld_safe_syslog.cnf I checked the /var/log/apt/history.log and mysql-server-5.5 was removed during the dist-upgrade. And this process does not purge config files. I do not know if it is really usefull to keep them. Regards, Jean-Marc pgplvJ49Tz1oV.pgp Description: PGP signature
Bug#824670: ITP: dnsdiag -- DNS Diagnostics and Performance Measurement Tools
On 2017-01-20 13:41:49, Antoine Beaupré wrote: > On 2017-01-20 16:23:02, Ana C. Custura wrote: >> Hi Antoine, >> >> Many thanks for the review, it is greatly appreciated. > > Alright, that looks all good to me. The only concern that remains is > that I just noticed a 1.5.1 release on PyPI that is not on github - i > wonder if we should be shipping that instead... > > I filed a bug upstream to try to get them to clarify that: > > https://github.com/farrokhi/dnsdiag/issues/33 > > That would affect where we point the watch file, among other things. I went ahead and just uploaded 1.4.0 as is so we get a slot in the NEW queue already. Congratulations! :) A. -- Use for yourself little but give to others much. - Albert Einstein
Bug#849932: libindicate: FTBFS (Fields cannot have void type)
On Mon, 02 Jan 2017 12:01:41 + Santiago Vilawrote: > Package: src:libindicate > Version: 0.6.92-3 > Severity: serious > > Dear maintainer: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: > > > [...] > debian/rules build-indep > CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use > source format 3.0 (quilt) instead > test -x debian/rules > mkdir -p "build" > CDBS WARNING:DEB_DH_BUILDDEB_ARGS is deprecated since 0.4.85 > mkdir -p debian/stamp-makefile-build debian/stamp-makefile-install > mkdir -p debian/stamp-makefile-check > mkdir -p debian/stamp-autotools > /usr/bin/make -f debian/rules reverse-config > make[1]: Entering directory '/<>' > CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use > source format 3.0 (quilt) instead > set -e; > if test -e debian/autoreconf.before; then \ > > [... snipped ...] > > && touch generated-stamp > Name: propertydata Type: GVariant* in callback > indicate_listener_get_property_variant_cb > Name: value Type: GVariant** in callback > indicate_server_get_indicator_property_group_slot_t > rettype: GVariant* in method GetPropertyVariant in type Indicate.Indicator > Name: value Type: GVariant* in indicate_indicator_set_property_variant in > method SetPropertyVariant in type Indicate.Indicator > Name: menu Type: DbusmenuServer* in indicate_server_set_menu in method > SetMenu in type Indicate.Server > Name: propertydata Type: GVariant* in callback GetPropertyVariantCallback > Defaulting GetPropertyTimeCallback param to 'call' scope in method > Listener.GetPropertyTime > Defaulting GetPropertyIntCallback param to 'call' scope in method > Listener.GetPropertyInt > Defaulting GetPropertyCallback param to 'call' scope in method > Listener.GetProperty > Defaulting GetPropertyBoolCallback param to 'call' scope in method > Listener.GetPropertyBool > Defaulting GetCountCallback param to 'call' scope in method > ListenerServer.GetCount > Defaulting GetDesktopCallback param to 'call' scope in method > ListenerServer.GetDesktop > Defaulting GetTypeCallback param to 'call' scope in method > ListenerServer.GetGType > Defaulting GetMenuCallback param to 'call' scope in method > ListenerServer.GetMenu > Defaulting GetIconThemeCallback param to 'call' scope in method > ListenerServer.GetIconTheme > > Generation Summary: > Enums: 1 Structs: 0 Boxed: 0 Opaques: 2 Interfaces: 0 Objects: 3 > Callbacks: 18 > Properties: 0 Signals: 2 Methods: 54 Constructors: 3 Throttled: 5 > Total Nodes: 88 > > /usr/bin/mono-csc > -keyfile:/<>/./bindings/mono/indicate/indicate.snk > -nowarn:0169,0612,0618 -unsafe -out:indicate-sharp.dll -target:library > -r:/usr/lib/pkgconfig/../../lib/cli/pango-sharp-2.0/pango-sharp.dll > -r:/usr/lib/pkgconfig/../../lib/cli/atk-sharp-2.0/atk-sharp.dll > -r:/usr/lib/pkgconfig/../../lib/cli/gdk-sharp-2.0/gdk-sharp.dll > -r:/usr/lib/pkgconfig/../../lib/cli/gtk-sharp-2.0/gtk-sharp.dll > -r:/usr/lib/pkgconfig/../../lib/cli/glib-sharp-2.0/glib-sharp.dll > ./generated/*.cs AssemblyInfo.cs > ./generated/ListenerServer.cs(62,10): error CS0670: Fields cannot have void > type > ./generated/ListenerServer.cs(62,28): error CS1547: Keyword `void' cannot be > used in this context > Compilation failed: 2 error(s), 0 warnings > Makefile:854: recipe for target 'indicate-sharp.dll' failed > make[6]: *** [indicate-sharp.dll] Error 1 > make[6]: Leaving directory > '/<>/build/gtk2/bindings/mono/indicate' > Makefile:546: recipe for target 'all-recursive' failed > make[5]: *** [all-recursive] Error 1 > make[5]: Leaving directory > '/<>/build/gtk2/bindings/mono/indicate' This is caused by gtk-sharp2 2.12.40 generating this line in file ListenerServer.cs: static void _gtype = new void (indicate_listener_server_get_type(listener == null ? IntPtr.Zero : listener.Handle, server == null ? IntPtr.Zero : server.Handle, cb_wrapper.NativeDelegate, IntPtr.Zero)); This line doesn't appear when building against the previous gtk-sharp2 release from snapshot.d.o (2.12.10). According to [1] it works with gtk-sharp2 2.12.29 as well. A bisect between releases 2.12.29 and 2.12.40 of gtk-sharp2 might give something. [1] https://github.com/chenxiaolong/Unity-for-Arch/issues/243 Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#853795: dpkg: Unable to disable .buildinfo generation
Package: dpkg Version: 1.18.21 Severity: normal Hi, Ubuntu ppa's (launchpad) do not support .buildinfo files and reject them: Rejected: Unable to identify file icinga2_2.6.1-1~ppa1~trusty1_source.buildinfo (admin) in changes. Further error processing not possible because of a critical previous error. Please make it possible to disable .buildinfo generation or inclusion in changes files. Thanks Alex -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8.1 ii libc62.24-9 ii liblzma5 5.2.2-1.2 ii libselinux1 2.6-3 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-5 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.4~beta4 pn debsig-verify -- no debconf information
Bug#511094: 848789
Bug#707903: drgeo: Migrate to guile-2.0?
[Stephen Kitt] > I agree it's sad... Upstream have switched to Pharo, so there won't be > any Guile 2.0 port from there! (And bootstrapping Pharo > seems... rather difficult.) Aha. Is there a WNPP request for Pharo? I was unable to find one. -- Happy hacking Petter Reinholdtsen
Bug#853097: Bug 853097
On Tue, 31 Jan 2017 09:06:54 +0100 Andreas Bilke wrote: > > First off, I wonder how they can support the loop option for > > > > \href{run:mymovie.avi?loop}{\includegraphics[width=0.5\textwidth]{figs/mymovie_first_frame}} > > then... > > Because we get the full uri (in this case `mymovie.avi?loop`) > via the poppler api and we can parse it as we like. > > In constrast, if you use the multimedia package, it will add a movie > annotation (instead of a link annotation in the previous example) to the > pdf. And with the glib API we can not get enought information from this > movie annotation. Andreas, thanks for clarifying this. It makes perfectly sense (shame on me for not understanding it in the first place!). As far as the feature request for poppler-glib is concerned, it seems to me that the implementation is already on the to do list of poppler library developers [1]: [...] | * glib frontend: | - Sound/Movie actions support [...] [1] https://cgit.freedesktop.org/poppler/poppler/tree/TODO Or am I misinterpreting this to do list entry? Maybe they just need some more motivation to implement it sooner, rather than later: I would strongly encourage you to file the feature request! Perhaps you will even manage to help them in getting this feature implemented... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpht52A_um2j.pgp Description: PGP signature
Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading
Hi everybody, I found time to test a dist-upgrade scenario starting from a brand new Jessie and upgrading to Stretch upgrading from mysql-5.5 to mariadb-10.1 (not exactly the one I got because I upgraded from mariadb-10.0 to 10.1) And everything went fine, mariadb-server-10.1 replaced mysql-server-5.5 without any problem. So, I think the bug can be closed. Regards, Jean-Marcpgp1yw5J26BBT.pgp Description: PGP signature
Bug#853794: gcc-defaults-ports: Missing packages for powerpcspe
Source: gcc-defaults-ports Version: 4:6.3.0-1 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi! Although current versions of the gcc package have been building without issues on powerpcspe, we're currently missing this architecture in gcc-defaults-ports meaning that packages like gcc-powerpc-linux-gnuspe. However, having these packages is important so powerpcspe can be enabled in build-essential as cross-build-essential-powerpcspe so that we're able to cross-build packages for powerpcspe. I have looked into gcc-defaults-ports and figured that after applying the changes from the attached patch, running debian/rules control, I was able to rebuild gcc-defaults-ports with the default gcc packages for powerpcspe enabled. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- gcc-defaults-ports-1.165/debian/rules 2017-01-21 19:07:52.0 +0100 +++ gcc-defaults-ports-1.165/debian/rules 2017-01-21 19:11:34.0 +0100 @@ -312,7 +312,7 @@ go_archs = alpha amd64 arm64 armel armhf i386 ia64 m68k \ mips mips64 mips64el mipsel \ - powerpc ppc64 ppc64el s390 s390x sparc sparc64 x32 + powerpc powerpcspe ppc64 ppc64el s390 s390x sparc sparc64 x32 go_multilib_archs = $(filter $(go_archs), $(filter-out armel armhf, $(multilib_archs))) @@ -337,6 +337,7 @@ HOST_ARCHS_mips64 = amd64 i386 x32 HOST_ARCHS_mips64el = amd64 i386 x32 HOST_ARCHS_powerpc = amd64 i386 x32 ppc64el +HOST_ARCHS_powerpcspe = amd64 i386 x32 ppc64el HOST_ARCHS_ppc64 = amd64 i386 x32 HOST_ARCHS_ppc64el = amd64 i386 x32 ppc64 HOST_ARCHS_s390x = amd64 i386 x32 @@ -348,9 +349,8 @@ CROSS_ARCHS ?= s390x ppc64el arm64 armhf armel \ $(if $(filter $(vendor), Ubuntu),, mips mipsel mips64el) else - CROSS_ARCHS ?= alpha hppa m68k mips64 powerpc ppc64 sh4 sparc64 \ + CROSS_ARCHS ?= alpha hppa m68k mips64 powerpc powerpcspe ppc64 sh4 sparc64 \ $(if $(filter $(vendor), Ubuntu), mips mipsel mips64el) - # powerpcspe, outdated, ftbfs endif with_cross = yes
Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Package: dpkg Version: 1.18.21 Severity: serious X-Debbugs-CC: debian-...@lists.debian.org Hi, [Disclaimer: I'm not an ARM porter and I don't really know much about the ARM psABI] The new ABI mismatch detector seems to be a bit too strict on armel and armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its user but checking ABI comparability doesn't seem that simple. For example, on armel linking against libgsm.so currently gives this: $ dpkg-shlibdeps -v -e../a.out -Ttest dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field) dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, libabi=0x010100280500 != objabi=0x0101002805000200 dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out (ELF format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '') dpkg-shlibdeps: debug: Library libc.so.6 found in /lib/arm-linux-gnueabi/libc.so.6 dpkg-shlibdeps: debug: Using symbols file /var/lib/dpkg/info/libc6:armel.symbols for libc.so.6 dpkg-shlibdeps: warning: binaries to analyze should already be installed in their package's directory dpkg-shlibdeps: error: cannot continue due to the error above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to generate a library which does not link against libc (this is used by sonames2elf in some packages) causes both flags to be set (maybe because it's compatible with both?). This was first seen with wine: https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0 https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0 But there seem to be some other recent build failures relating to this as well. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#853153: It can't start by a segmentation fault
Michel Dänzer wrote: > Looks like this happens because SMI_ScreenInit calls xf86HandleColormaps > before xf86CrtcScreenInit, but xserver >= 1.19 requires the opposite order. Aha, thank you! I don't have any LynxEM+ hardware to test with until next week, but I've attached a patch for xserver-xorg-video-siliconmotion, if Jonny would like to try rebuilding with this perhaps. Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/src/smi_driver.c b/src/smi_driver.c index 8949cae..5023e63 100644 --- a/src/smi_driver.c +++ b/src/smi_driver.c @@ -1787,6 +1787,9 @@ SMI_ScreenInit(SCREEN_INIT_ARGS_DECL) "Hardware cursor initialization failed\n"); } +if(!xf86CrtcScreenInit(pScreen)) + LEAVE(FALSE); + /* Initialise default colormap */ if (!miCreateDefColormap(pScreen)) LEAVE(FALSE); @@ -1810,9 +1813,6 @@ SMI_ScreenInit(SCREEN_INIT_ARGS_DECL) SMI_InitVideo(pScreen); -if(!xf86CrtcScreenInit(pScreen)) - LEAVE(FALSE); - /* Report any unused options (only for the first generation) */ if (serverGeneration == 1) { xf86ShowUnusedOptions(pScrn->scrnIndex, pScrn->options); signature.asc Description: Digital signature
Bug#853792: res_rtp_asterisk.c: Unable to allocate RTP socket: Address family not supported by protocol
Package: asterisk Version: 1:13.13.1~dfsg-2 Severity: important Tags: upstream After upgrading asterisk (1:13.12.2~dfsg-2 => 1:13.13.1~dfsg-2) I wasn't able to make calls anymore, the message displayed by Linphone was 'Not acceptable here' and the following error was logged on asterisk host: [2017-02-01 08:26:01] WARNING[1600] res_rtp_asterisk.c: Unable to allocate RTP socket: Address family not supported by protocol [2017-02-01 08:26:01] WARNING[1600] res_rtp_asterisk.c: Failed to create a new socket for RTP instance '0x7fcea4049f30' [2017-02-01 08:26:01] ERROR[1600] res_pjsip_sdp_rtp.c: Unable to create RTP instance using RTP engine 'asterisk' Because I have IPv6 disabled (in /etc/defaults/grub using: GRUB_CMDLINE_LINUX="ipv6.disable=1") this was my first suspect which google soon confirmed. A bug was introduced in Asterisk 13.13.0 which was reported in https://issues.asterisk.org/jira/browse/ASTERISK-26617 and the fix will be included in next (13.13.2) asterisk release. Until then, IPv6 needs to be enabled or Asterisk version 13.12.x used instead -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages asterisk depends on: ii adduser 3.115 ii asterisk-config 1:13.13.1~dfsg-2 ii asterisk-core-sounds-en [asterisk-prompt-en] 1.4.27-1 ii asterisk-core-sounds-en-gsm 1.4.27-1 ii asterisk-modules 1:13.13.1~dfsg-2 ii init-system-helpers 1.47 ii libbsd0 0.8.3-1 ii libc6 2.24-8 ii libcap2 1:2.25-1 ii libedit2 3.1-20160903-3 ii libgcc1 1:6.3.0-5 ii libjansson4 2.9-1 ii libncurses5 6.0+20161126-1 ii libpopt0 1.16-10 ii libsqlite3-0 3.16.2-1 ii libssl1.1 1.1.0c-2 ii libstdc++66.3.0-5 ii libsystemd0 232-14 ii libtinfo5 6.0+20161126-1 ii liburiparser1 0.8.4-1 ii libuuid1 2.29-1 ii libxml2 2.9.4+dfsg1-2.1 ii libxslt1.11.1.29-2 ii lsb-base 9.20161125 Versions of packages asterisk recommends: ii asterisk-moh-opsound-gsm 2.03-1 ii asterisk-voicemail [asterisk-voicemail-storage] 1:13.13.1~dfsg-2 ii sox 14.4.1-5+b1 Versions of packages asterisk suggests: pn asterisk-dahdi pn asterisk-dev pn asterisk-doc pn asterisk-ooh323 pn asterisk-opus pn asterisk-vpb -- no debconf information
Bug#853790: ITP: golang-github-aanand-compose-file -- Parser for the Docker compose file format version 3
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-aanand-compose-file Version : 0.0~git20161122.0.a3e5876-1 Upstream Author : Aanand Prasad * URL : https://github.com/aanand/compose-file * License : Apache-2.0 Programming Lang: Go Description : Parser for the Docker compose file format version 3 This library implements a parser for the Docker compose file format. Docker Compose is a tool for defining and running multi-container Docker applications. Applications can then be created and started using a single command. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853789: ITP: golang-github-azure-go-ansiterm -- Go package for ANSI terminal emulation in Windows
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-azure-go-ansiterm Version : 0.0~git20160622.0.fa152c5-1 Upstream Author : John Starks, Gabriel Hartmann * URL : https://github.com/Azure/go-ansiterm * License : Expat Programming Lang: Go Description : Go package for ANSI terminal emulation in Windows This package is a cross-platform ANSI terminal emulation library. It reads a stream of Ansi characters and produces the appropriate function calls. The results of the function calls are platform dependent. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#851513: Build failing
I can confirm that packages built manually from https://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/zfs.git and https://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git , which include fixes for this bug (thanks Aron!), seem to resolve this issue.
Bug#852751: Why not fix buggy encfs behavior?
On 31/01/2017 19:43, .. ink .. wrote: Greetings,i am a current maintainer of a project called "SiriKali"[1][4] and it is also affected[2] by this bug in encfs. encfs upstream has said that this "new" behavior of encfs is a bug that needs to be fixed[3]. Why not fix this buggy encfs behavior and let cryptkeeper among other front ends to encfs continue to work as expected? This bug is not in cryptkeeper,its in encfs and continuing with this buggy behavior of encfs will break a lot more projects than SiriKali and cryptkeeper and will cause encfs in debian to behave differently from everybody else when upstream release a new version that does not have this behavior. I think cryptkeeper should be left alone and focus be redirected to the change in encfs behavior that upstream now disagrees with that started all this. [1] https://mhogomchungu.github.io/sirikali/ [2] https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276288921 [3] https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206 [4] https://packages.debian.org/sid/sirikali Hello, thanks for the comment. Maybe a better solution could be to check output of encfs before piping anything, or maybe, we can do a mount result check to see if all worked fine; but we can't send "p" command trusting that encfs is waiting for a choice between "p" and "x". This is my humble opinion. Cheers, Francesco
Bug#853788: ITP: golang-github-docker-goamz -- Enable Go programs to interact with Amazon Web Services
X-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Tim Potter* Package name: golang-github-docker-goamz Version : 0.0~git20160206.0.f0a21f5-1 Upstream Author : Docker * URL : https://github.com/docker/goamz * License : LGPL-3.0 Programming Lang: Go Description : Enable Go programs to interact with Amazon Web Services The goamz package enables Go programs to interact with the Amazon Web Services including AWS, EC2, S3, ELB, SQS and SNS. . It was developed within Canonical as part of an experiment related to using the Go language with the juju project, but is now a set of generally adopted and maintained Go packages that talk to several Amazon Web Services. . This package is a fork of the GOAMZ version developed within Canonical with additional functionality and services, including DynamoDB. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading
Thank you very much Jean-Marc for helping with testing! Can you please also try running apt-get purge mysql-* and see if it removes the remnants cleanly? But not too cleanly, mysqld binary or /var/lib/mysql used by mariadb-10.1 should not get deleted by the mysql purge (one user reported he suffered such a case).
Bug#825864: ITP: sedutil -- Tool to use functionality of Self Encrypting Drives (SED) that comply with the TCG OPAL 2.00 standard
Gentlemen; I was wondering if there is any progress toward packaging sedutil in Debian? Much thanks. Mark Stingley Network Security Architect UTHealth | The University of Texas Health Science Center at Houston 7000 Fannin St | Suite M50-F | Houston, Texas 77030 https://inside.uth.edu/itsecurity/sac/phishing-awareness/
Bug#853787: wxmaxima: loadfile: failed to load /usr/share/wxMaxima/wxmathml.lisp
Package: wxmaxima Version: 16.12.2-1 Severity: important Dear Maintainer, I wanted to use a wxMaxima package,but I'm unable to,because It don't want to load wxmathml.lisp file,which performs all of the calculations in wxMaxima.it just appears in main window of the program. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wxmaxima depends on: ii ibus-gtk31.5.14-2 ii imagemagick 8:6.9.7.4+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-1 ii libc62.24-9 ii libgcc1 1:6.3.0-5 ii libstdc++6 6.3.0-5 ii libwxbase3.0-0v5 3.0.2+dfsg-2 ii libwxgtk3.0-0v5 3.0.2+dfsg-2 ii maxima 5.38.1-8 ii maxima-doc 5.38.1-8 Versions of packages wxmaxima recommends: ii fonts-jsmath 0.090709+0-3 ii texlive-latex-extra 2016.20170123-1 wxmaxima suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#2297: Very Urgent
Regards from me to you i have a promising proposal for you write me through this mail:: mrswangju...@gmail.com Yours Faithfully, Mrs. Wang.
Bug#853786: ITP: golang-github-cbroglie-mapstructure -- Go library for decoding generic map values into native Go structures
Package: wnpp Severity: wishlist Owner: Tim PotterX-Debbugs-CC: debian-de...@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org * Package name: golang-github-cbroglie-mapstructure Version : 0.0~git20150405.0.25325b4-1 Upstream Author : Chris Broglie * URL : https://github.com/cbroglie/mapstructure * License : Expat Programming Lang: Go Description : Go library for decoding generic map values into native structures mapstructure is a Go library for decoding generic map values to structures and vice versa, while providing helpful error handling. . This library is most useful when decoding values from some data stream (JSON, Gob, etc.) where you don't quite know the structure of the underlying data until you read a part of it. You can therefore read a map[string]interface{} and use this library to decode it into the proper underlying native Go structure. . This package is a fork of the golang-github-mitchellh-mapstructure package to more elegantly support decoding data with an unknown structure by using the runtime reflection features of the Go language. signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#853726: tunnelx: Dead link in man page
On 2017-01-31 11:09 +, Toby Speight wrote: > Package: tunnelx > Version: 20160713-3 > Severity: normal > > Sorry, no patch this time, because I couldn't find a fix! > > The manual page says: > > / > | This manual page was written for the Debian distribution because the > | original program does not have a manual page. Instead, it has > | excellent documentation online at > | http://www.freesteel.co.uk/wiki/index.php/Tunnel . Please refer to > | that. > \ > > Sadly, the "excellent documentation" is no longer available from that > URI - I get a HTTP 404 response. There seems to be a cached copy at > http://expo.survex.com/expofiles/tunnelwiki/www.freesteel.co.uk/wiki/index.php/Tunnel.html > > - yes. I put it there after the original disappeared. I'll fix the URL. > although I'm having trouble accessing that as it's not providing a > HTTPS version properly. It doesn't need to. Just because https is a good idea on those new-fangled sites that require you to be logged in so you can be properly tracked like a good little internet-user, there is no reason to provide the expo website as https. So tell your browser to piss off and let you browse as you see fit :-) We have many more important things to fix first. > Perhaps there's a case (given a sufficient supply of Round Tuits) for > creating a 'tunnelx-doc' package with a snapshot of that documentation > (if the licensing permits)? Yes. That would probably be a good idea. I used to package the therion wiki in a -doc package. I'll leave this bug open as a wishlist reminder. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#853756: debian-installer: no cryptsetup available in rescue mode
Toni Mueller(2017-01-31): > > Toni Mueller (2017-01-31): > > > I downloaded the testing installer using Jigdo from here: > > > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo > > > because the Jessie installer in 8.7.1 would not work for me (#750586). > > > > Well that isn't D-I Stretch RC 1 then. That one lives under: > > http://cdimage.debian.org/cdimage/stretch_di_rc1/ > > I'm confused - the testing CD does not use the latest d-i? See description here: http://cdimage.debian.org/cdimage/weekly-builds/ “latest d-i” is ambiguous. It can be the latest d-i build (see https://d-i.debian.org/daily-images/daily-build-overview.html), or the latest d-i release (D-I Stretch RC 1 right now). The image you're trying to use uses the former definition of “latest d-i”, as explained on the link above. > > Anyway, trying this image: > > f234f4aa708bdb226c0f412e85c37541c654526e > > downloads/debian-testing-amd64-netinst.iso > > I could set up an encrypted partition in the installation procedure, > just not access it during the rescue operation. > > $ sha1sum debian-testing-amd64-netinst.iso > 1d50301e6eccba6b116253f323cf397cfccd88fe debian-testing-amd64-netinst.iso > > Your image is different. I downloaded "mine" this morning, btw. I downloaded the iso directly instead of going through the jigdo dance, because it's oh so simpler, but maybe I hit a different iso, which would be slightly surprising… Anyway, I'm busy trying to find a workaround for RC 2 right now, so I'll avoid spending more time on this. > I used the manual method, because I wanted to have a RAID1 underneath. OK, fair. I know for a fact this works with Debian 8 since I've used this many time for Debian/Linux teaching sessions, with RAID1 and encrypted LVM on top of it; purposefully breaking the encrypted LVM (removing cryptsetup) then repairing from rescue mode. > > Given my test results above, we'll need those… > > Ok. I'll see what I can do. Thanks already! KiBi. signature.asc Description: Digital signature
Bug#811576: tpm-utils 1.3.9 fixes this issue
On 01/31/2017 09:55 PM, Adrian Bunk wrote: > Which tarball are you using, and do you have the build dependency > libopencryptoki-dev installed? Yay conditional compilation. I didn't forward port the packaging yet. > I am using the one from > https://sourceforge.net/projects/trousers/files/tpm-tools/1.3.9/ > > and the error I get is: > > ... > gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -D_LINUX -Wdate-time > -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/tmp/tpm-tools-1.3.9=. > -fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall > -Wreturn-type -Wsign-compare -c -o data_import.o data_import.c > data_import.c: In function 'readX509Cert': > data_import.c:375:26: error: dereferencing pointer to incomplete type > 'EVP_PKEY {aka struct evp_pkey_st}' > if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) { > ^~ > In file included from /usr/include/openssl/asn1.h:24:0, > from /usr/include/openssl/rsa.h:16, > from data_import.c:34: > data_import.c: In function 'createRsaPubKeyObject': > data_import.c:694:34: error: dereferencing pointer to incomplete type 'RSA > {aka struct rsa_st}' > int nLen = BN_num_bytes( a_pRsa->n ); > ^ > Makefile:524: recipe for target 'data_import.o' failed > make[4]: *** [data_import.o] Error 1 > make[4]: Leaving directory '/tmp/tpm-tools-1.3.9/src/data_mgmt' > Makefile:401: recipe for target 'all-recursive' failed > make[3]: *** [all-recursive] Error 1 I suppose all this needs is the following patch. I'm a little unhappy about the naming of the intermediate variables, but I suppose as long as it does the trick: > Index: tpm-tools/src/data_mgmt/data_import.c > === > --- tpm-tools.orig/src/data_mgmt/data_import.c > +++ tpm-tools/src/data_mgmt/data_import.c > @@ -372,7 +372,7 @@ readX509Cert( const char *a_pszFile, > goto out; > } > > - if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) { > + if ( EVP_PKEY_base_id( pKey ) != EVP_PKEY_RSA ) { > logError( TOKEN_RSA_KEY_ERROR ); > > X509_free( pX509 ); > @@ -691,8 +691,13 @@ createRsaPubKeyObject( RSA > > int rc = -1; > > - int nLen = BN_num_bytes( a_pRsa->n ); > - int eLen = BN_num_bytes( a_pRsa->e ); > + const BIGNUM *bn; > + const BIGNUM *be; > + > + RSA_get0_key( a_pRsa, , , NULL ); > + > + int nLen = BN_num_bytes( bn ); > + int eLen = BN_num_bytes( be ); > > CK_RV rv; > > @@ -732,8 +737,8 @@ createRsaPubKeyObject( RSA > } > > // Get binary representations of the RSA key information > - BN_bn2bin( a_pRsa->n, n ); > - BN_bn2bin( a_pRsa->e, e ); > + BN_bn2bin( bn, n ); > + BN_bn2bin( be, e ); > > // Create the RSA public key object > rv = createObject( a_hSession, tAttr, ulAttrCount, a_hObject ); > @@ -760,14 +765,27 @@ createRsaPrivKeyObject( RSA > > int rc = -1; > > - int nLen = BN_num_bytes( a_pRsa->n ); > - int eLen = BN_num_bytes( a_pRsa->e ); > - int dLen = BN_num_bytes( a_pRsa->d ); > - int pLen = BN_num_bytes( a_pRsa->p ); > - int qLen = BN_num_bytes( a_pRsa->q ); > - int dmp1Len = BN_num_bytes( a_pRsa->dmp1 ); > - int dmq1Len = BN_num_bytes( a_pRsa->dmq1 ); > - int iqmpLen = BN_num_bytes( a_pRsa->iqmp ); > + const BIGNUM *bn; > + const BIGNUM *be; > + const BIGNUM *bd; > + const BIGNUM *bp; > + const BIGNUM *bq; > + const BIGNUM *bdmp1; > + const BIGNUM *bdmq1; > + const BIGNUM *biqmp; > + > + RSA_get0_key( a_pRsa, , , ); > + RSA_get0_factors( a_pRsa, , ); > + RSA_get0_crt_params( a_pRsa, , , ); > + > + int nLen = BN_num_bytes( bn ); > + int eLen = BN_num_bytes( be ); > + int dLen = BN_num_bytes( bd ); > + int pLen = BN_num_bytes( bp ); > + int qLen = BN_num_bytes( bq ); > + int dmp1Len = BN_num_bytes( bdmp1 ); > + int dmq1Len = BN_num_bytes( bdmq1 ); > + int iqmpLen = BN_num_bytes( biqmp ); > > CK_RV rv; > > @@ -821,14 +839,14 @@ createRsaPrivKeyObject( RSA > } > > // Get binary representations of the RSA key information > - BN_bn2bin( a_pRsa->n, n ); > - BN_bn2bin( a_pRsa->e, e ); > - BN_bn2bin( a_pRsa->d, d ); > - BN_bn2bin( a_pRsa->p, p ); > - BN_bn2bin( a_pRsa->q, q ); > - BN_bn2bin( a_pRsa->dmp1, dmp1 ); > - BN_bn2bin( a_pRsa->dmq1, dmq1 ); > - BN_bn2bin( a_pRsa->iqmp, iqmp ); > + BN_bn2bin( bn, n ); > + BN_bn2bin( be, e ); > + BN_bn2bin( bd, d ); > + BN_bn2bin( bp, p ); > + BN_bn2bin( bq, q ); > + BN_bn2bin( bdmp1, dmp1 ); > + BN_bn2bin( bdmq1, dmq1 ); > + BN_bn2bin( biqmp, iqmp ); > > // Create the RSA private key object > rv = createObject( a_hSession, tAttr, ulAttrCount, a_hObject ); There's also no test suite, which is unhelpful. Hence
Bug#853785: RM: tightvnc [mips mips64el mipsel] -- ROM; FTBFS
Package: ftp.debian.org I'd like you to remove two binary packages xtightvncviewer and tightvncserver from testing as it prevents tightvnc from entering testing. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Bug#815212: lilypond: Changing the output paper size is "hard"
Control: tags -1 - wontfix Hi Karl, Thank you for your follow up. On Tue, Jan 31, 2017 at 10:22 AM, Karl O. Pincwrote: > On Mon, 30 Jan 2017 22:29:46 -0700 Anthony Fok wrote: >> Rather, the officially documented method is outlined in >> http://lilypond.org/doc/v2.18/Documentation/notation/paper-size-and-automatic-scaling, >> i.e., by setting the paper size in the .ly file itself: >> >> \paper { >> #(set-paper-size "letter") >> } > > Ok. I probably went to the man page first, to wind up using the > command line option. > >> I use Frescobaldi (a great GUI editor for LilyPond) myself, and its >> Score Wizard feature automatically generates needed skeleton LilyPond >> code for you, together with the set-paper-size command above. >> >> I highly recommend that you do the same instead, i.e. using >> Frescobaldi (sudo apt-get install frescobaldi) and setting the paper >> size inside your .ly file. > > Thanks. But I'm not interested in a GUI. Sorry for my poor choice of words. Frescobaldi is actually more a text editor with the added benefits of creating the overall structure of the .ly file, things like \header, \paper, lyrics, \score section etc. for you. After that, the end user still needs to go to the appropriate sections and enter notes like "c2 d4 e | f2 g" manually. It is none of those GUI entering-notes-by-clicking-with-the-mouse things which I am not used to myself either. Of course, LilyPond is self-sufficient on its own, and you definitely don't need Frescobaldi per se. But yes, it is very handy for both newbies and professional music engravers like Frescobaldi's author who organized and coordinated the production of a professionally-printed Dutch hymnal called "Liedboek" a few years ago. It is a tremendous time-saver and learning aid, and that is why I highly recommended that you at least give it a try. >> Changing the paper size on-the-fly using -dpaper-size is unreliable >> IMHO. You yourself may remember to add the "-dpaper-size letter" >> option, but others who receive the same .ly file with are not obliged >> to do so, and would get unexpected results such as extra page, ugly >> line-breaks, etc. due to unexpectedly different page width and page >> height. > > Good advice. Makes sense to me that every lilypond input file > contain a paper size specification. > > (Perhaps this should be a recommendation in the lilypond manual.) It *is* in the manual (info page, HTML and PDF). As a matter of fact, it is the only documented method, so I guess that would count as a recommendation? :-) Seriously though, I have gotten used to using on-line search engines, and thankfully, a search on "LilyPond paper size" on Google or DuckDuckGo.com gives me the correct LilyPond HTML documentation page as its first result. I find it easier than to search through the locally installed documentation, actually. :-) >> The fact that LilyPond does not read /etc/papersize is by design, and >> I think it is a good thing. Ignoring user environment variations like >> /etc/papersize helps ensure that the same .ly would produce the >> exactly same result everywhere. > > This sounds laudable, but unrealistic. I don't have any a4 paper, > the default, and this is probably true for almost everybody in North > America. > > My feeling is that if the author of the lilypond file did not > explicitly specify a paper size then lilypond should be free > to print on the paper available. Even if it means > that the result comes out looking different. If the composer wants > to ensure conformity in print output it's up to the composer > to do so. Otherwise, the composer should be allowed to distribute > music to be printed on whatever paper the musician has available. You have a good point there, but it is a design decision that both LilyPond (default: A4) and TeX/LaTeX (default: US Letter) have made. Another user has brought up the same issue some years ago. Check out the following conversations for an interesting read: http://lilypond.1069038.n5.nabble.com/LC-PAPER-and-default-paper-size-td131547.html > Speaking as a novice, I'd like to be able to typeset some music > and print it with minimum effort. It's bad enough having to figure > out lilypond itself without having > oh-my-!-now-I-have-to-deal-with-paper-size issues. Haha, been there, done that. (Oh yes, the learning pain.) > If you're expecting everybody to use a GUI that takes care of paper > size issues that's one thing, but it seems to me that the lilypond > packaging should at least have some options available for non-GUI > users. No, it wasn't the GUI with preset template, it was that Google search on "LilyPond paper size" or other creative searches to find helpful documentation or forum posts and useful snippets. Otherwise, how do you think I would come up with the following "monstrosity" to be able to change the "paper size" to fit 1280x720 (16:9 aspect ratio) for screen projection?
Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations
Hi, I forgot an important piece of the patch which is actually adding the build-dependency: --- a/debian/control +++ b/debian/control @@ -15,6 +15,7 @@ Build-Depends: dh-systemd , dpkg-dev (>= 1.16.1~), flex, + libbsd-dev (>= 0.8.1~) [!linux-any], libevent-dev, libexpat1-dev, libfstrm-dev , 0.8.1 was the first version to implement a modern arc4random (using ChaCha20 cipher) and implement genentropy on kfreebsd and hurd. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#800588: [debian-mysql] Bug#800588: Upgrade from jessie
Micah, According to your logs, you had mysql-server 5.5.54-0+deb8u1 and then upgraded to mysql-server 5.6.30-1. So your bug is about MySQL, not about MariaDB. The libmariadbclient18 library you had installed does not affect mysqld before or after in any way. Indeed Bug#800588 is filed agains mysql-server, which is no longer in Debian Stretch. For the time being I am trying to focus on Stretch issues as it is close to freeze and release.
Bug#846099: ping
Any news on this? There's a fair amount of (Russian) spam coming in daily that's quite annoying. signature.asc Description: PGP signature
Bug#852346: kdenlive: crash on startup
On Tue, 2017-01-31 at 21:56 +0100, Vincent Pinon wrote: > Hello, > > Actually this is Kdenlive bug 375094, fixed just after 16.12.1 release :( > See Kdenlive revert commit 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e > (attached as patch) > > Actually the following commit in 16.12 branch also fixes NVidia crash with > GPU effects: > kdenlive commit 754b8eeed8c1a874a5535eb5136b02841a812180 > (attached too) > > maybe worth to include in a 16.12.1-2 for stretch users, if not too late? > (16.12.2 won't come on time) > > Cheers and thanks to all, > > Vincent Thanks for the analysis! Patrick, are you happy for me to punt these bugs back to kdenlive then? Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#721600: Wrong priority
FWIW, a simple: sudo cp /lib/udev/rules.d/52-nut-usbups.rules /etc/udev/rules.d/63-nut-usbups.rules fixed this issue for me on a jessie system, with freshly installed nut-server 2.7.2-4 (I never had nut-server installed on this system before).
Bug#853107: xapian-core: FTBFS under pbuilder with USENETWORK=no
Hi Olly, > Daniel: What version of pbuilder are you using? If it's more than a > year old, then upgrading will probably fix this. If not, then either > that fix has regressed in pbuilder regression, or else something more > complex is going on. This is happening here [1] as well, which is a recent pbuilder version, I guess. I'm wondering if this is a bug in pbuilder or a wrapper around. Cheers, Georg (who debugged for some hours a similar problem over here [2]...) [1] https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/xapian-core_1.4.3-1.rbuild.log [2] https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/schleuder_3.0.1-1.rbuild.log signature.asc Description: Digital signature
Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.
Control: reassign 853066 pinentry-gnome3 Control: reassign 845565 pinentry-gnome3 Control: forcemerge 845565 853066 841909 Le Tue, Jan 31, 2017 at 03:38:23PM +0100, Vincent Lefevre a écrit : > On 2017-01-31 22:57:07 +0900, Charles Plessy wrote: > > Control: forcemerge -1 845565 > > Note that the bug was merged to itself. Do not use -1 when several > bugs are mentioned in To/Cc. I think that both bugs 845565 and > 853066 should be reassigned to pinentry-gnome3, *then* forcemerge'd > with bug 841909. Argh, sorry for the mess ! > > Do you think it might help to put the Debian GNOME maintainers in the > > loop ? Perhaps there is a GNOMEish way to ensure that the GNOME tools > > are launched in GNOME context, and text tools are launched in text > > context. > > In my case, I do not use GNOME at all, but expect X11 tools in a X11 > context (e.g. pinentry-gtk-2). IMHO, either pinentry-gnome3 should > detect the context and do the necessary fallback(s), or a pinentry > wrapper should be preferred to the alternatives system: it would > detect the context and launch the right pinentry-* program (with > fallback when not installed). Indeed, I think that pinentry-gnome3 should not be called in this context. For instance, from my SSH session, if I type `sudo apt install foo`, my password is prompted in text mode in the SSH session, not as a popup on a distant computer. Similarly, if I type `exit`, then the SSH session where I entered the command is ended; I do not get a popup on the distant computer asking if I want to close the graphical session instead. I think that the gpg ~ gpg-agent ~ pinentry chain should to the same: prompting the user at the location where the user ran the command, as it used to do in Jessie. I understand that this UI problem is quite far from what the Debian GnuPG Maintainers are able to commit to solve, and that the freeze is near. So where is the best place to call for help ? Perhaps planet.debian.org ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Bug#853784: schleuder: accesses the internet during build
Source: schleuder Version: 3.0.1-1 Severity: important Justification: Policy 4.9 User: la...@debian.org Usertags: network-access Dear Maintainer, Whilst schleuder builds successfully on unstable/amd64, according to Debian Policy 4.9 packages may not attempt network access during a build. 00:00:00.00 IP 1bda71ae498f.21600 > OpenWrt.lan.domain: 53623+ PTR? 1.0.0.127.in-addr.arpa. (40) 00:00:00.001484 IP OpenWrt.lan.domain > 1bda71ae498f.21600: 53623* 1/0/0 PTR localhost.lan. (67) 00:00:00.001604 IP 1bda71ae498f.24754 > OpenWrt.lan.domain: 15484+ PTR? 1.0.0.127.in-addr.arpa. (40) 00:00:00.002947 IP OpenWrt.lan.domain > 1bda71ae498f.24754: 15484* 1/0/0 PTR localhost.lan. (67) 00:00:01.289711 IP 1bda71ae498f.31343 > OpenWrt.lan.domain: 2272+ PTR? 1.0.0.127.in-addr.arpa. (40) 00:00:01.291147 IP OpenWrt.lan.domain > 1bda71ae498f.31343: 2272* 1/0/0 PTR localhost.lan. (67) 00:00:06.308390 IP 1bda71ae498f.21600 > OpenWrt.lan.domain: 53623+ PTR? 1.0.0.127.in-addr.arpa. (40) 00:00:06.309862 IP OpenWrt.lan.domain > 1bda71ae498f.21600: 53623* 1/0/0 PTR localhost.lan. (67) 00:00:06.309992 IP 1bda71ae498f.24754 > OpenWrt.lan.domain: 15484+ PTR? 1.0.0.127.in-addr.arpa. (40) 00:00:06.311301 IP OpenWrt.lan.domain > 1bda71ae498f.24754: 15484* 1/0/0 PTR localhost.lan. (67) [..] The full build log (including tcpdump output) is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- schleuder.3.0.1-1.unstable.amd64.log.txt.gz Description: Binary data
Bug#853756: debian-installer: no cryptsetup available in rescue mode
Hi KiBi, On Tue, Jan 31, 2017 at 09:20:53PM +0100, Cyril Brulebois wrote: > Control: notfound -1 20170112 > Control: tag -1 moreinfo > > Toni Mueller(2017-01-31): > > I downloaded the testing installer using Jigdo from here: > > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo > > because the Jessie installer in 8.7.1 would not work for me (#750586). > > Well that isn't D-I Stretch RC 1 then. That one lives under: > http://cdimage.debian.org/cdimage/stretch_di_rc1/ I'm confused - the testing CD does not use the latest d-i? > > > Were you prompted with a passphrase for the detected LUKS partition? > > When I tried to run the installer in the "rescue" mode, it did not > > prompt me with anything, but when it said something like "partition > > disks", it did not have any crypto entries. On the console, it was > > complaining about two missing modules, one of which ended with _crypto. > > > > I looked for cryptsetup, but could not find it. > > cryptsetup is the component installed in /target (the installed system), > not what d-i uses. > > Anyway, trying this image: > f234f4aa708bdb226c0f412e85c37541c654526e > downloads/debian-testing-amd64-netinst.iso I could set up an encrypted partition in the installation procedure, just not access it during the rescue operation. $ sha1sum debian-testing-amd64-netinst.iso 1d50301e6eccba6b116253f323cf397cfccd88fe debian-testing-amd64-netinst.iso Your image is different. I downloaded "mine" this morning, btw. > with a VM installed with guided encrypted LVM, and starting graphical > rescue mode, I'm getting prompted for a passphrase to unlock /dev/sda5 > as expected, so d-i seems to behave properly. I used the manual method, because I wanted to have a RAID1 underneath. > > > Syslog might be interesting (vt4, or /var/log/syslog from another vt). > > > > :/ > > > > I am sorry, but currently I can't produce those logs. > > Given my test results above, we'll need those… Ok. I'll see what I can do. Cheers, --Toni++
Bug#853008: [debian-mysql] Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning
- j...@debian.org wrote: > On Mon, Jan 30, 2017 at 06:38:16PM +, Robie Basak wrote: > > > So how about this, just a sketch at the moment rather than a full > > > patch? > > > > Your sketch seems good to me, assuming that "dpkg-query --search" > is > > permitted from maintainer scripts (I know there are some > re-entrancy > > problems with some particular types of dpkg-related invocations?) > > [...] > > > > I wondered this too. But without thinking it through in more > detail, > > it'd certainly be better than what we have now. > > Please find attached a patch against the current > mysql-5.7/debian/master branch on alioth. I have also updated the > github branch for mariadb-10.1 to address the same issue (the one > with > a pull request to otto/mariadb-10.1). > > It's been tested for upgrades, clean install, remove and purge. > > Best wishes, > >Julian Thanks! I'll look it over and test a little myself. -- Lars
Bug#827068: m2crypto: doesn't work together with OpenSSL 1.1 (API changes)
On 2016-11-15 12:36:09 [+0100], Daniel Stender wrote: > On Mon, 14 Nov 2016 19:52:31 +0100 Daniel Stender> wrote: > > The diff doesn't work like that on the upstream code in the archive > > ... the same is true for 0.25.1. > > I'm on it. Should I take 0.25.1 and cherry-pick the patches or B-D on openssl 1.0 for Stretch? > DS > Sebastian
Bug#811576: tpm-utils 1.3.9 fixes this issue
On Tue, Jan 31, 2017 at 09:24:34PM +0100, Philipp Kern wrote: > Hi, > > On 01/31/2017 07:46 PM, Adrian Bunk wrote: > > On Tue, Jan 31, 2017 at 04:02:53PM +0100, Philipp Kern wrote: > >> so tpm-utils 1.3.9 fixes OpenSSL 1.1 compatibility > > does 1.3.9 compile for you with OpenSSL 1.1? > > 1.3.9 still has two issues with -Werror, but none with OpenSSL 1.1 AFAICS. >... Which tarball are you using, and do you have the build dependency libopencryptoki-dev installed? I am using the one from https://sourceforge.net/projects/trousers/files/tpm-tools/1.3.9/ and the error I get is: ... gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -D_LINUX -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/tmp/tpm-tools-1.3.9=. -fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall -Wreturn-type -Wsign-compare -c -o data_import.o data_import.c data_import.c: In function 'readX509Cert': data_import.c:375:26: error: dereferencing pointer to incomplete type 'EVP_PKEY {aka struct evp_pkey_st}' if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) { ^~ In file included from /usr/include/openssl/asn1.h:24:0, from /usr/include/openssl/rsa.h:16, from data_import.c:34: data_import.c: In function 'createRsaPubKeyObject': data_import.c:694:34: error: dereferencing pointer to incomplete type 'RSA {aka struct rsa_st}' int nLen = BN_num_bytes( a_pRsa->n ); ^ Makefile:524: recipe for target 'data_import.o' failed make[4]: *** [data_import.o] Error 1 make[4]: Leaving directory '/tmp/tpm-tools-1.3.9/src/data_mgmt' Makefile:401: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 ... > Kind regards > Philipp Kern cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#852346: kdenlive: crash on startup
Hello, Actually this is Kdenlive bug 375094, fixed just after 16.12.1 release :( See Kdenlive revert commit 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e (attached as patch) Actually the following commit in 16.12 branch also fixes NVidia crash with GPU effects: kdenlive commit 754b8eeed8c1a874a5535eb5136b02841a812180 (attached too) maybe worth to include in a 16.12.1-2 for stretch users, if not too late? (16.12.2 won't come on time) Cheers and thanks to all, Vincent>From 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e Mon Sep 17 00:00:00 2001 From: Jean-Baptiste MardelleDate: Mon, 16 Jan 2017 20:06:00 +0100 Subject: [PATCH 1/9] Revert "Fix warning about QOffscreenSurface thread" Caused startup crash on NVidia cards CCBUG: 375094 This reverts commit 6675c4a509046aa3b57c60cbc3f31435e09c2df7. --- src/monitor/glwidget.cpp | 10 +++--- src/monitor/glwidget.h | 1 - 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/src/monitor/glwidget.cpp b/src/monitor/glwidget.cpp index e4089e661..cd4f56add 100644 --- a/src/monitor/glwidget.cpp +++ b/src/monitor/glwidget.cpp @@ -109,7 +109,6 @@ GLWidget::GLWidget(int id, QObject *parent) mlt_properties_set_data(mlt_global_properties(), "glslManager", NULL, 0, NULL, NULL); emit gpuNotSupported(); } -connect(this, SIGNAL(sceneGraphInitialized()), SLOT(createOffscreen())); connect(this, SIGNAL(sceneGraphInitialized()), SLOT(initializeGL()), Qt::DirectConnection); connect(this, SIGNAL(beforeRendering()), SLOT(paintGL()), Qt::DirectConnection); } @@ -143,17 +142,14 @@ void GLWidget::updateAudioForAnalysis() m_frameRenderer->sendAudioForAnalysis = KdenliveSettings::monitor_audio(); } -void GLWidget::createOffscreen() +void GLWidget::initializeGL() { +if (m_isInitialized || !isVisible() || !openglContext()) return; if (!m_offscreenSurface.isValid()) { m_offscreenSurface.setFormat(openglContext()->format()); m_offscreenSurface.create(); +openglContext()->makeCurrent(this); } -} - -void GLWidget::initializeGL() -{ -if (m_isInitialized || !isVisible() || !openglContext()) return; initializeOpenGLFunctions(); qDebug() << "OpenGL vendor: " << QString::fromUtf8((const char*) glGetString(GL_VENDOR)); qDebug() << "OpenGL renderer: " << QString::fromUtf8((const char*) glGetString(GL_RENDERER)); diff --git a/src/monitor/glwidget.h b/src/monitor/glwidget.h index dc1e0e2f3..d12500a57 100644 --- a/src/monitor/glwidget.h +++ b/src/monitor/glwidget.h @@ -182,7 +182,6 @@ private slots: void updateTexture(GLuint yName, GLuint uName, GLuint vName); void paintGL(); void onFrameDisplayed(const SharedFrame ); -void createOffscreen(); protected: void resizeEvent(QResizeEvent* event); -- 2.11.0 >From 754b8eeed8c1a874a5535eb5136b02841a812180 Mon Sep 17 00:00:00 2001 From: Jean-Baptiste Mardelle Date: Fri, 20 Jan 2017 01:15:01 +0100 Subject: [PATCH 2/9] Fix NVIDIA crash with GPU accel (movit) --- src/main.cpp| 2 +- src/mltcontroller/producerqueue.cpp | 14 +- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/main.cpp b/src/main.cpp index fc93963de..b081e056f 100644 --- a/src/main.cpp +++ b/src/main.cpp @@ -44,7 +44,7 @@ int main(int argc, char *argv[]) // Force QDomDocument to use a deterministic XML attribute order extern Q_CORE_EXPORT QBasicAtomicInt qt_qhash_seed; qt_qhash_seed.store(0); - +QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts, true); #if defined(Q_OS_UNIX) && !defined(Q_OS_MAC) QCoreApplication::setAttribute(Qt::AA_X11InitThreads); #endif diff --git a/src/mltcontroller/producerqueue.cpp b/src/mltcontroller/producerqueue.cpp index 07fd234d3..aa06cf6fb 100644 --- a/src/mltcontroller/producerqueue.cpp +++ b/src/mltcontroller/producerqueue.cpp @@ -299,7 +299,19 @@ void ProducerQueue::processFileProperties() } else if (service.contains(QStringLiteral("avformat"))) { Mlt::Profile *blankProfile = new Mlt::Profile(); blankProfile->set_explicit(false); -blankProfile->from_producer(*producer); +if (KdenliveSettings::gpu_accel()) { +Clip clp(*producer); +Mlt::Producer *glProd = clp.softClone(ClipController::getPassPropertiesList()); +Mlt::Filter scaler(*m_binController->profile(), "swscale"); +Mlt::Filter converter(*m_binController->profile(), "avcolor_space"); +glProd->attach(scaler); +glProd->attach(converter); +blankProfile->from_producer(*glProd); +delete glProd; +} +else { +blankProfile->from_producer(*producer); +}
Bug#853198: simple-cddd cannot handle reprepro home made d-i repository
Control: tags 853198 wontfix On 2017-01-30, Laurent COOPER wrote: > I tried to use simple-cdd to build a set of CD with a customised > debian-installer > I have a personnal debian repository with a custom debian installer. It's all > handled with reprepro > > The problem is about signature of the files > > In official repository, Release file has a hash for the SHA256 file in > main/debian-installer branche > > Reprepro does not handle this ... > As reprepro does not handle control sums for main/installer , simple-cdd > failed with no clue. I'd recommend using the custom_installer option, which specifies a path to a custom built installer image, which skips the verification step for the installer. With "custom_installer=/path/to/dir", it should search for the installer files at: /path/to/dir/$ARCH/ or /path/to/dir/installer-$ARCH/current/ > Should this verification be turned into a warning or at least be > switchable in config or by command line option swicth? I don't really like the idea of simple-cdd adding workarounds for incomplete mirrors. In general, simple-cdd is designed to work with the official debian mirrors, and only add a small number of additional custom packages or configurations. live well, vagrant signature.asc Description: PGP signature
Bug#853744: cloud-init needs net-tools
> "Marco" == Marco d'Itriwrites: Marco> On Jan 31, Sam Hartman wrote: >> Why? I can understand "it would be nice if cloud-init used ip >> instead", but you seem to have a preference stronger than that. Marco> To save space on the images. I think having it work is more important than space. I think applying the patch and then opening a wishlist bug to use iproute2 would be a good path forward.
Bug#853783: libsane-hpaio: Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error during device I/O
Package: libsane-hpaio Version: 3.16.11+repack0-2 Severity: important Hello, Upgrading libane-hpaio (and hplip*, etc) to 3.16.11+repack0-2 makes the scanner non-functional. (The same applies to 3.16.10+repack0-1 and 3.16.9+repack0-2). Even if awahi-daemon is running the message is: Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error during device I/O. Searching for the printer works (as well as the printer itself): scanimage -L device `hpaio:/net/HP_Color_LaserJet_MFP_M277dw?ip=192.168.1.4' is a Hewlett- Packard HP_Color_LaserJet_MFP_M277dw all-in-one Installed driver is: hp-color_laserjet_pro_mfp_m277-ps.ppd.gz downloaded from HP. Previous working version is: 3.16.7-1 Printer/Scanner/Copier/Faxer: Network connected HP Color Laserjet Pro MFP M277dw Tested software: scanimage, xscanimage, simple-scan
Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu
> "Ole" == Ole Streicherwrites: Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman: >> If you go back one meeting further, my interpretation is that the >> consensus of the committee seems to be that ultimately this >> decision belongs to the installer team. That is, in this case, a >> number of members on the TC seem to believe that the installer >> team gets to decide whether/how the installer makes it easy to >> install blends. If they don't want to do that for stretch, >> that's a decision within their pervue that we clearly don't have >> the votes to override. Ole> Hmm, IMO there are two things here: First, in our constitution, Ole> the installer team has no specific granted rights, apart from Ole> being maintainers of the relevant packages. This makes the Ole> conflict primarily a conflict between developers having Ole> different opinions about how to solve a certain problem. A Ole> decision here falls under the rights granted to the Technical Ole> Team by the Project leader. I think you mean by the constitution. I could see that argument. Ole> And I would expect that a decision Ole> would be made on some technical foundation. A lot of people expect that. A lot of what the TC does involves understanding how to balance technical and non-technical factors. It seems entirely appropriate for the TC to look at the technical issues here and decide who should be making the decision rather than to make a decision. What I think several of us did is look at the technical details and decide we believe that the installer team was the right set of people to make this technical decision. So, I think the TC will make its decisions on a technical foundation a lot less frequently than you do. That said, I do think an understanding of which technical factors are important is something we need to do. If there are things I can to to help you believe that we did consider the points you think important I'd like to do that. If you can think of things I can do to help you gain confidence that we have heard you, please let me know. That said, I'm hoping you can respect me when I say that hearing you does not mean agreeing with you--not even about what factors are important in making a decision. --Sam
Bug#828482: bug 828482 fix
On 2016-10-27 08:56:23 [+0800], Di-Shi Sun wrote: > osptoolkit/3.4.2-1.2 is out of date and osptoolkit/4.11.3+dfsg-1 has been > released to replace it. so what? 4.11.3+dfsg-1 is still affected by this problem. > Regards, > > > > Di-Shi Sun > VoIP Routing, Accounting, Security Sebastian
Bug#853285: ghc: Patch to add support for cross-compilation of GHC
On 01/31/2017 08:17 PM, Helmut Grohne wrote: > On Tue, Jan 31, 2017 at 09:20:46AM +0100, John Paul Adrian Glaubitz wrote: >> Setting "--target" allows enabling cross-compiling, adding >> --enable-unregisterised is important for architectures not >> having native code generation support. Disabling the documentation >> is required by GHC itself. Trying to build the documentation >> when cross-compiling causes an error message. > > I'm not entirely sold on the idea that we cannot cross build haddock. > What about using the haddock from the ghc:native package to build the > documentation? But then maybe I understand too little of the > requirements here. Oh, I'm absolutely with you on this. The problem is just that GHC upstream currently doesn't support building the documentation when cross-building because of these lines in the main ghc.mk makefile: ifneq "$(CrossCompiling) $(Stage1Only)" "NO NO" $(error Can not build haddock docs when CrossCompiling or Stage1Only. \ Set HADDOCK_DOCS=NO in your mk/build.mk file. \ See Note [No stage2 packages when CrossCompiling or Stage1Only]) endif endif > In any case, disabling haddock should not be a thing that just happens > for cross compilation. We want cross builds to be reproducible (when > compared against native builds). So disabling haddock should be a > concious choice (even if cross building without disabling haddock > doesn't work). Also building ghc without haddock should produce a > package that doesn't list haddock under Provides. This calls for a build > profile. So I went ahead and split out this part of your patch into a > patch that adds a pkg.ghc.nohaddock build profile. I actually want the cross-built GHC package to match the natively built package as closely as possible because I prefer it as an alternative to building GHC on slower architectures. Building GHC on m68k can take over 20 days since m68k also doesn't have a native code generator. > I hope that this makes sense and that the resulting profile is useful > for cross compiling ghc. Do you agree? As long as the cross-built GHC package can be fully used on the target system, I'm all for these changes. But, as I explained in my initial report, the are still issues with ghc-pkg when trying to build haskell-text that I haven't resolved yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#811576: tpm-utils 1.3.9 fixes this issue
Hi, On 01/31/2017 07:46 PM, Adrian Bunk wrote: > On Tue, Jan 31, 2017 at 04:02:53PM +0100, Philipp Kern wrote: >> so tpm-utils 1.3.9 fixes OpenSSL 1.1 compatibility > does 1.3.9 compile for you with OpenSSL 1.1? 1.3.9 still has two issues with -Werror, but none with OpenSSL 1.1 AFAICS. Specifically it still needs this: > Index: tpm-tools/src/tpm_mgmt/tpm_nvcommon.c > === > --- tpm-tools.orig/src/tpm_mgmt/tpm_nvcommon.c > +++ tpm-tools/src/tpm_mgmt/tpm_nvcommon.c > @@ -164,8 +164,8 @@ int parseStringWithValues(const char *aA > return -1; > } > > - if (!aArg[offset+numbytes] == '|' && > - !aArg[offset+numbytes] == 0) { > + if (aArg[offset+numbytes] == '|' || > + aArg[offset+numbytes] == 0) { > logError(_("Illegal character following decimal > " > "number in %s\n"), >aArg + offset); > Index: tpm-tools/src/tpm_mgmt/tpm_present.c > === > --- tpm-tools.orig/src/tpm_mgmt/tpm_present.c > +++ tpm-tools/src/tpm_mgmt/tpm_present.c > @@ -357,5 +357,5 @@ out_close: > out: > if (szTpmPasswd && !isWellKnown) > shredPasswd( szTpmPasswd ); > - return iRc; > +return iRc; > } I'd hold that -Werror is a problem in itself, but the comparison warning was actually appreciated: > tpm_nvcommon.c: In function ‘parseStringWithValues’: > tpm_nvcommon.c:167:31: warning: comparison of constant ‘124’ with boolean > expression is always false [-Wbool-compare] > if (!aArg[offset+numbytes] == '|' && >^~ > tpm_nvcommon.c:167:31: warning: logical not is only applied to the left hand > side of comparison [-Wlogical-not-parentheses] So what happened is that the upstream maintainer only fixed one of the two identical comparisons (the one for hexadecimals, not the one for decimals). With that I think we should be fine to upload this. It's quite late, though, so it will need a little convincing of the Release Team. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#850883: libapache2-mod-auth-cas: diff for NMU version 1.1-2.1
Control: tags 850883 + patch Dear maintainer, I've prepared an NMU for libapache2-mod-auth-cas (versioned as 1.1-2.1). The diff is attached to this message. Regards. Sebastian diff -Nru libapache2-mod-auth-cas-1.1/debian/changelog libapache2-mod-auth-cas-1.1/debian/changelog --- libapache2-mod-auth-cas-1.1/debian/changelog 2016-11-03 09:41:34.0 +0100 +++ libapache2-mod-auth-cas-1.1/debian/changelog 2017-01-31 21:23:57.0 +0100 @@ -1,3 +1,10 @@ +libapache2-mod-auth-cas (1.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build depend open OpenSSL 1.0 for Stretch (Closes: #850883). + + -- Sebastian Andrzej SiewiorTue, 31 Jan 2017 21:23:57 +0100 + libapache2-mod-auth-cas (1.1-2) unstable; urgency=medium * Update configure for OpenSSL 1.1 (closes: #828378). diff -Nru libapache2-mod-auth-cas-1.1/debian/control libapache2-mod-auth-cas-1.1/debian/control --- libapache2-mod-auth-cas-1.1/debian/control 2016-11-03 09:41:29.0 +0100 +++ libapache2-mod-auth-cas-1.1/debian/control 2017-01-31 21:23:18.0 +0100 @@ -3,7 +3,7 @@ Priority: extra Maintainer: CAS packaging team Uploaders: Michele Baldessari , Thijs Kinkhorst -Build-Depends: debhelper (>= 9), dh-apache2, apache2-dev, libssl-dev, libcurl4-openssl-dev, libpcre3-dev, dpkg-dev (>= 1.16.1) +Build-Depends: debhelper (>= 9), dh-apache2, apache2-dev, libssl1.0-dev | libssl-dev (<< 1.1), libcurl4-openssl-dev, libpcre3-dev, dpkg-dev (>= 1.16.1) Standards-Version: 3.9.8 Vcs-Svn: https://anonscm.debian.org/pkg-cas/libapache2-mod-auth-cas/svn-buildpackage/trunk/ Vcs-Browser: https://anonscm.debian.org/viewsvn/pkg-cas/libapache2-mod-auth-cas/svn-buildpackage/trunk/
Bug#853756: debian-installer: no cryptsetup available in rescue mode
Control: notfound -1 20170112 Control: tag -1 moreinfo Hi, Toni Mueller <supp...@oeko.net> (2017-01-31): > I downloaded the testing installer using Jigdo from here: > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo > because the Jessie installer in 8.7.1 would not work for me (#750586). Well that isn't D-I Stretch RC 1 then. That one lives under: http://cdimage.debian.org/cdimage/stretch_di_rc1/ > > Were you prompted with a passphrase for the detected LUKS partition? > > When I tried to run the installer in the "rescue" mode, it did not > prompt me with anything, but when it said something like "partition > disks", it did not have any crypto entries. On the console, it was > complaining about two missing modules, one of which ended with _crypto. > > I looked for cryptsetup, but could not find it. cryptsetup is the component installed in /target (the installed system), not what d-i uses. Anyway, trying this image: f234f4aa708bdb226c0f412e85c37541c654526e downloads/debian-testing-amd64-netinst.iso (According to syslog: Jan 31 20:15:20 cdrom-detect: Detected CD 'Debian GNU/Linux testing "Stretch" - Official Snapshot amd64 NETINST Binary-1 20170131-16:00') with a VM installed with guided encrypted LVM, and starting graphical rescue mode, I'm getting prompted for a passphrase to unlock /dev/sda5 as expected, so d-i seems to behave properly. > > Syslog might be interesting (vt4, or /var/log/syslog from another vt). > > :/ > > I am sorry, but currently I can't produce those logs. Given my test results above, we'll need those… KiBi. signature.asc Description: Digital signature
Bug#828449: net-snmp will stay with 1.0 for stretch
control: retitle -1 net-snmp: Please migrate to openssl1.1 in buster control: unblock 827061 with -1 Dmitry, in [0] you said, that this bug affects zabbix. If it is still the case, please explain how otherwise please remove the `affects' tag. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828449;msg=25 Sebastian
Bug#848813: blacs-mpi: FTBFS: make[3]: *** No rule to make target '/usr/lib/openmpi/include/mpif.h', needed by 'mpif.h'. Stop.
Control: tags -1 + patch On Sun, 1 Jan 2017 17:38:52 +0500 Andrey Rahmatullinwrote: > On Mon, Dec 19, 2016 at 10:26:42PM +0100, Lucas Nussbaum wrote: > > > make[3]: *** No rule to make target '/usr/lib/openmpi/include/mpif.h', > > > needed by 'mpif.h'. Stop. > The /usr/lib/openmpi path is hardcoded in > debian/blacs-mpi-implementations.patch and should be replaced with the > correct triplet path. Indeed. The attached patch does the trick. Thanks, _g. diff -u blacs-mpi-1.1/debian/blacs-mpi-implementations.patch blacs-mpi-1.1/debian/blacs-mpi-implementations.patch --- blacs-mpi-1.1/debian/blacs-mpi-implementations.patch +++ blacs-mpi-1.1/debian/blacs-mpi-implementations.patch @@ -73,7 +73,7 @@ +endif +ifeq ($(MPI),openmpi) +# for compilation with openmpi: -+ MPIdir = /usr/lib/openmpi ++ MPIdir = /usr/lib/$(DEB_HOST_MULTIARCH)/openmpi + MPILIBdir = $(MPIdir)/lib + MPIINCdir = $(MPIdir)/include + MPILIB = $$(pkg-config mpi-fort --libs) signature.asc Description: OpenPGP digital signature
Bug#850882: lastpass-cli: diff for NMU version 1.0.0-1.2
Control: tags 850882 + patch Dear maintainer, I've prepared an NMU for lastpass-cli (versioned as 1.0.0-1.2). The diff is attached to this message. Regards. Sebastian diff -Nru lastpass-cli-1.0.0/debian/changelog lastpass-cli-1.0.0/debian/changelog --- lastpass-cli-1.0.0/debian/changelog 2016-12-06 21:10:47.0 +0100 +++ lastpass-cli-1.0.0/debian/changelog 2017-01-31 21:05:57.0 +0100 @@ -1,3 +1,10 @@ +lastpass-cli (1.0.0-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Switch to openssl 1.0 (Closes: #850882). + + -- Sebastian Andrzej SiewiorTue, 31 Jan 2017 21:05:57 +0100 + lastpass-cli (1.0.0-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru lastpass-cli-1.0.0/debian/control lastpass-cli-1.0.0/debian/control --- lastpass-cli-1.0.0/debian/control 2016-10-20 16:17:08.0 +0200 +++ lastpass-cli-1.0.0/debian/control 2017-01-31 21:05:24.0 +0100 @@ -2,7 +2,7 @@ Section: utils Priority: optional Maintainer: Troy Heber -Build-Depends: debhelper (>= 9), quilt (>= 0.47), libssl-dev, libxml2-dev, libcurl4-openssl-dev, asciidoc, xsltproc, docbook-xsl +Build-Depends: debhelper (>= 9), quilt (>= 0.47), libssl1.0-dev | libssl-dev (<< 1.1), libxml2-dev, libcurl4-openssl-dev, asciidoc, xsltproc, docbook-xsl Standards-Version: 3.9.8.0 Package: lastpass-cli