Bug#909152: libreoffice: Google Drive file listing fails with "General input/output error"
found 909152 1:6.1.1~rc1-2 thanks Hi, On Wed, Sep 19, 2018 at 02:31:21AM +, Stephen Paul Weber wrote: > This has previously been reported to upstream: > https://bugs.documentfoundation.org/show_bug.cgi?id=117271 but in fact > it works in upstream's version so they closed it and suggested reporting > to Ubuntu, which was done: > https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1754400 and > it seems they found a fix for their version: > > > after we explicitly enabled the google drive API for the project that > > holds the API key used in libreoffice (it was not enabled previously) > > > From this I infer that distribution packages of libreoffice are using > their own Google API credentials different from those of upstream, and Of course, that's at least nominally a secret. And upstream doesn't give us this secret (then it de-facto wouldn't be secret anymore given it has to be in the source package somewhere to use it.) > that an option needs to be enabled on these credentials to allow Google > Drive access. Hmm. Maybe. CC'ing the chromium maintainers (where we get the id/"secret" from) - - from /etc/chromium.d/apikeys... Can you check whether said option is enabled for the id/"secret"? Regards, Rene
Bug#909157: anbox: please enable --software-rendering, contingent on packaging of SwiftShader
Package: anbox
Version: 0.0~git20180821-1
Severity: wishlist
Tags: patch
Control: block -1 with 909156
https://bugs.debian.org/909156 is an RFP for packaging SwiftShader as
an independent library in debian.
If that was done, then i believe that something like the following
patch would enable the use of the --software-rendering without the
snap package:
diff --git a/src/anbox/graphics/gl_renderer_server.cpp
b/src/anbox/graphics/gl_renderer_server.cpp
index beb2cbe..3e21596 100644
--- a/src/anbox/graphics/gl_renderer_server.cpp
+++ b/src/anbox/graphics/gl_renderer_server.cpp
@@ -80,11 +80,7 @@ GLRendererServer::GLRendererServer(const Config ,
const std::shared_ptr{
{emugl::GLLibrary::Type::EGL, (swiftshader_path / "libEGL.so").string()},
{emugl::GLLibrary::Type::GLESv1, (swiftshader_path /
"libGLES_CM.so").string()},
I hope this is useful. Thanks very much for maintaining anbox in
debian!
Regards,
--dkg
Bug#909156: RFP: swiftshader -- high-performance CPU-based implementation of OpenGL ES graphics APIs
Package: wnpp
Severity: wishlist
Control: affects -1 anbox chromium-browser
* Package name: swiftshader
Version : 0+git20180914.0.25c541e+dfsg1-0
Upstream Author : The ANGLE Project Authors
* URL : https://swiftshader.googlesource.com/SwiftShader
* License : Apache 2.0
Programming Lang: C++
Description : high-performance CPU-based implementation of OpenGL ES
graphics APIs
SwiftShader is a high-performance CPU-based implementation of the
OpenGL ES and Direct3D 9 graphics APIs. Its goal is to provide
hardware independence for advanced 3D graphics.
On GNU/Linux platforms, it will only provide an OpenGL ES
implementation and not Direct3D 9.
It is concretely useful for running OpenGL-based on systems with
decent CPU but without dedicated graphics hardware. For example,
running anbox with the --software-rendering argument.
Note that there is already a copy of SwiftShader in debian, in the
chromium-browser sources at third_party/swiftshader. (another copy
exists in qtwebengin-opensource-src, embedded itself in an embedded
copy of chromium.
speaking of third_party bundling, upstream swiftshader appears to be
keen on a lot of bundling as well, and we can and should
repack/minimize the source to not bother including stuff we do not
need to include (or which we do not have a DFSG-free license for).
As of git version 25c541e51cbdb0406f9010d7f20c4fa03a4b0fa8 (the head
of upstream's https://swiftshader.googlesource.com/SwiftShader git
repository as i write this), we can exclude:
.gitmodules
third_party/
Note that the following directory is not even DFSG-free:
third_party/PowerVR_SDK/
given this stripping, CMakeLists.txt can be cleaned up with the
attached patch series to make the swiftshader cleanly and simply
buildable on debian.
I'm not well-prepared to maintain this myself, but having it in debian
would be nice for several reasons:
* we could potentially use it for chromium-browser, if the package
maintainers want to use system libraries
* it should make it possible to encourage anbox to permit
--software-renderer without being installed via "snap"
* It might make for a sensible backend for the libegl1 or libgles2 or
libgles1 dispatchers, though i don't know that i understand the
dispatch architecture well enough to be confident in how this can
happen.
Would anyone be interested in co-maintenance?
--dkg
commit b0b61117ca82e70e0c165c892a717b7f4f97a99f
Author: Daniel Kahn Gillmor
Date: Tue Sep 18 17:41:52 2018 -0400
debian has googletest
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 95766810..e8099454 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -89,19 +89,6 @@ endif()
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
-###
-# Initialize submodules
-###
-
-if(NOT EXISTS ${CMAKE_SOURCE_DIR}/third_party/googletest)
-message(WARNING "
- third_party/googletest submodule missing.
- Running 'git submodule update --init' to download it:
-")
-
-execute_process(COMMAND git submodule update --init)
-endif()
-
###
# Convenience macros
###
@@ -2079,12 +2066,12 @@ endif()
if(BUILD_TESTS AND ${REACTOR_BACKEND} STREQUAL "Subzero")
set(SUBZERO_TEST_LIST
${SOURCE_DIR}/Reactor/Main.cpp
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/src/gtest-all.cc
+/usr/src/googletest/googletest/src/gtest-all.cc
)
set(SUBZERO_TEST_INCLUDE_DIR
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/include
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/
+/usr/src/googletest/googletest/include
+/usr/src/googletest/googletest/
)
add_executable(SubzeroTest ${SUBZERO_TEST_LIST})
@@ -2103,13 +2090,13 @@ if(BUILD_TESTS)
set(UNITTESTS_LIST
${CMAKE_SOURCE_DIR}/tests/unittests/main.cpp
${CMAKE_SOURCE_DIR}/tests/unittests/unittests.cpp
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/src/gtest-all.cc
+/usr/src/googletest/googletest/src/gtest-all.cc
)
set(UNITTESTS_INCLUDE_DIR
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/include/
-${CMAKE_SOURCE_DIR}/third_party/googletest/googlemock/include/
-${CMAKE_SOURCE_DIR}/third_party/googletest/googletest/
+/usr/src/googletest/googletest/include/
+/usr/src/googletest/googlemock/include/
+/usr/src/googletest/googletest/
${CMAKE_SOURCE_DIR}/include/
)
commit f796785dcd76b711d210f657a623ebefd765d07f
Author: Daniel Kahn Gillmor
Date: Wed Sep 19 00:49:57 2018 -0400
use debian LLVM, rather than embedded copy
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e8099454..578d80ce 100644
--- a/CMakeLists.txt
+++
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Hi Adam, On 09/17/2018 12:12 PM, Adam Borowski wrote: > ! LaTeX Error: File `subfigure.sty' not found. seems to a missing dependency again. This time I've tried dropping all texlive-* packages to detect ones needed. Could you please pull and try it one more time? Many thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#908494: lightning: no icon to access calendar after upgrade to TB 60
Just use $(LANG=C /usr/bin/thunderbird) to make lightning works again. This bug is reproducible on my daily Stretch.
Bug#909155: apt-cache show multiple packages produces invalid output
Package: apt Version: 1.7.0~rc1 Severity: serious File: /usr/bin/apt-cache If you do a fresh sid debootstrap and then you can get the following interaction: $ apt-cache show gcc-8-base=installed libgcc1=installed Package: gcc-8-base Source: gcc-8 Version: 8.2.0-7 Installed-Size: 244 Maintainer: Debian GCC Maintainers Architecture: amd64 Breaks: gcc-4.4-base (<< 4.4.7), gcc-4.7-base (<< 4.7.3), gcj-4.4-base (<< 4.4.6-9~), gcj-4.6-base (<< 4.6.1-4~), gnat-4.4-base (<< 4.4.6-3~), gnat-4.6 (<< 4.6.1-5~) Description: GCC, the GNU Compiler Collection (base package) Description-md5: b6e93638a6d08ea7a18929d7cf078e5d Multi-Arch: same Homepage: http://gcc.gnu.org/ Tag: role::shared-lib Section: libs Priority: optional Filename: pool/main/g/gcc-8/gcc-8-base_8.2.0-7_amd64.deb Size: 187052 MD5sum: 5ae3d2f575c9924ae67fa8dcc4af1e21 SHA256: 9e3dcd13005ccadbb57a8f117cde66aec8b8b8a21492e3aa02d6f54c1288bfb4 Package: libgcc1 Source: gcc-8 (8.2.0-7) Version: 1:8.2.0-7 Installed-Size: 116 Maintainer: Debian GCC Maintainers Architecture: amd64 Depends: gcc-8-base (= 8.2.0-7), libc6 (>= 2.14) Breaks: gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2) Description: GCC support library Description-md5: bbd60d723e97d8e06c04228ee4c76f10 Tag: role::shared-lib Section: libs Priority: optional Filename: pool/main/g/gcc-8/libx32gomp1_8.2.0-7_amd64.deb Size: 77204 MD5sum: 61275848d23df37f647cb6a9b21f4135 SHA256: b8c56221460897e2640baf7bd6e1a9f645346d4178265508a18d48bf8c68e752 Package: libx32gomp1-dbg Source: gcc-8 Version: 8.2.0-7 Installed-Size: 346 Maintainer: Debian GCC Maintainers
Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure
-=| Xavier, 18.09.2018 22:58:48 +0200 |=-
> Le 15/09/2018 à 17:42, Damyan Ivanov a écrit :
> > Adding
> > $SIG{PIPE} = 'IGNORE';
> > at the start of the test seems to make it pass all the time.
> >
> > I wonder if this is the correct fix.
> >
> > -- Damyan
>
> Hello,
>
> I added this hook without success. "reproducible" builds well [1] but
> not buildd [2]
>
> [1]
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnet-server-mail-perl.html)
> [2]
> https://buildd.debian.org/status/package.php?p=libnet-server-mail-perl
The buildd used libio-socket-ssl-perl 2.059-1, which misses a lot of
openssl 1.1.1 fixes.
Perhaps bumping the (build) dependency to version 2.060-3 would help?
Hmm, the reproducible-builds log also shows 2.059-1, but I guess
bumping the version is still worth a try -- may be the failure is hard
to trigger.
-- dam
Bug#855416: [Pkg-nagios-devel] Bug#855416: check_running_kernel: don't search /boot/lost+found
On 9/19/18 1:18 AM, Konrad Bauckmeier wrote: > I run into the same problem. The proposed solution works for me. > Sorry for asking, since I am a newbie: Is there any reason, that the > patch was not accepted yes? Not enough manpower in the team. If you have time and motivation, please join the team and help maintain the packages you use. Kind Regards, Bas
Bug#909153: [src:zfs-linux]
Most of the packaging complexity has already been dealt with in my debian/git branch. I've collected the fraction needed for 8.0-rc1 into [1] (see also [2] and [3]). The main remaining task, I believe, is to make sure all the files are properly represented in debian/copyright. The package, as it stands, appears to be completely functional (I use it, and one person [4] is probably also using this). > I'm recently working on the 0.7.11 update for the compatibility with > linux 4.18, and would be happy to try to push 0.8.0-rc1 to experimental after > finishing the 0.7.11 work. So I wonder which version of zfs should Buster > ship with? Is it 0.7.x or the upcoming 0.8.x? I was thinking about this too. Do we know what kernel Buster will ship with? If 0.7.x supports it, I'd vote for that (given how gigantic the changes are going to be for 0.8.0). > And as pointed out by Aron, mixing the source of GPL-licensed SPL and > CDDL-licensed ZFS would be "interesting". I haven't investigated into > this yet. I brought this up on the debian-legal mailing list (see [5], I cc-ed them, but heard nothing). I don't think we're in any difficult legal grounds here: mere aggregation of work doesn't change anything. No single file combines GPL and CDDL code (which would presumably not be distributable), but then again IANAL. [1] https://salsa.debian.org/aerusso-guest/zfs/commits/debian/pulls/8.0 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891890 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900862 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908290 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902165
Bug#909154: dolphin: renaming files with unusual/non-displayable characters in name doesn't work
Package: dolphin This problem is quite general. It has affected Dolphin for years. I sometimes get files with undisplayable characters in them - the character(s) show up as � When I get this, the file cannot be renamed, moved, copied or even deleted. I get a "file or folder does not exist" error if I try. I cannot see this as anything but a bug. I should be able to work with any file that exists on my system, even if Dolphin or Plasma can't display its name. Sorry this isn't produced using reportbug. My current ISP is giving me a lot of headaches with sending e-mail from accounts it doesn't recognize and I haven't fixed the one used by reportbug. To make matters worse, the tmp file saved by reportbug is now base64 encoded so I can't copy it to a Thunderbird e-mail.
Bug#904558: What should happen when maintscripts fail to restart a service
Stuart Prescott dijo [Wed, Sep 19, 2018 at 12:18:24PM +1000]: > (...) > That was perhaps also written before we started to realise that maintainer > scripts are actually best avoided as they tend to be complicated, fragile, > difficult to do right and make upgrades harder for the package manager. In > the intervening two decades, we've gone from "maintainer scripts are cool" > to "the best maintainer script is the one that doesn't exist". > > So yes, ignoring errors seems wrong but… > (...) > … causing a snowball of errors in an awkward half-upgraded environment is > nasty. > > The problem comes when you don't yet have the right tools installed to be > able to fix the problem. We see that scenario often enough in #debian where > someone has a failed upgrade and we try to collect more information via > pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover > that the relevant tool isn't installed and because apt is sufficiently > unhappy about broken packages and a half-completed upgrade, you can't ask it > to install the tool at that point in time. > > In the upgrade scenario, while you're trying to fix one particular problem, > you're also in a completely untested half-upgraded situation and so latent > bugs in any number of other tools may also be exposed. > > So while ignoring errors is wrong, so is making it harder to fix them. This > isn't a question of absolutes. I completely agree with Stuart here. Yes, of course, there is a reason for maintainer scripts to exist, and if they fail to set up things around the package, of course, the user _needs_ to know something is off in their system. But that should happen _very_ seldom. As Stuart says, helping non-technical users out of this situation can be quite hard, and quite discouraging for the user. We have to make sure the scripts are as foolproof as possible — and failing to stop or restart a daemon it should _never_ cause the system to enter such a state. signature.asc Description: PGP signature
Bug#909153: zfs 0.8.x will bring significant change to Debian packaging
Source: zfs-linux Version: 0.8.0-1 X-Debbugs-CC: a...@debian.org, p...@debian.org, clo...@igalia.com Hello ZFS team, Upstream has released the preview version 0.8.0-rc1 several days ago. And it must be pointed out that, upstream is going to merge the source of spl and zfs together. See 1. https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.8.0-rc1 2. https://github.com/zfsonlinux/spl/commit/5712fadef19a28d27038b04f8267f29109794fc3 That means src:spl-linux will nolonger exist since ZFS 0.8.x, and we'll have to move all binary packages of src:spl-linux to src:zfs-linux. As a consequence the ZFS package has to go through NEW queue again. And as pointed out by Aron, mixing the source of GPL-licensed SPL and CDDL-licensed ZFS would be "interesting". I haven't investigated into this yet. I'm recently working on the 0.7.11 update for the compatibility with linux 4.18, and would be happy to try to push 0.8.0-rc1 to experimental after finishing the 0.7.11 work. So I wonder which version of zfs should Buster ship with? Is it 0.7.x or the upcoming 0.8.x?
Bug#909152: libreoffice: Google Drive file listing fails with "General input/output error"
Package: libreoffice Version: 1:5.2.7-1+deb9u4 Severity: normal Dear Maintainer, After installing libreoffice and libreoffice-gnome I tried to use the "open remote files" option and use my Google Drive account. It did log in (Google emails me to say so) but instead of a files listing I get "General input/output error" This has previously been reported to upstream: https://bugs.documentfoundation.org/show_bug.cgi?id=117271 but in fact it works in upstream's version so they closed it and suggested reporting to Ubuntu, which was done: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1754400 and it seems they found a fix for their version: after we explicitly enabled the google drive API for the project that holds the API key used in libreoffice (it was not enabled previously) From this I infer that distribution packages of libreoffice are using their own Google API credentials different from those of upstream, and that an option needs to be enabled on these credentials to allow Google Drive access. The rest of the comments on the Ubuntu bug are about 2FA issues which are a different problem not related to this (my account has no 2FA enabled). -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice depends on: ii libreoffice-avmedia-backend-gstreamer 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-base 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-calc 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-core 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-draw 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-impress1:6.1.1~rc1-2~bpo9+1 ii libreoffice-math 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-report-builder-bin 1:6.1.1~rc1-2~bpo9+1 ii libreoffice-writer 1:6.1.1~rc1-2~bpo9+1 ii python3-uno1:6.1.1~rc1-2~bpo9+1 Versions of packages libreoffice recommends: pn fonts-crosextra-caladea pn fonts-crosextra-carlito ii fonts-dejavu2.37-1 ii fonts-liberation1:1.07.4-2 ii fonts-liberation2 2.00.1-3 pn fonts-linuxlibertine ii fonts-noto-hinted 20161116-1 ii fonts-noto-mono 20161116-1 ii fonts-sil-gentium-basic 1.1-7 ii libreoffice-java-common 1:6.1.1~rc1-2~bpo9+1 pn libreoffice-librelogo pn libreoffice-nlpsolver pn libreoffice-ogltrans pn libreoffice-report-builder pn libreoffice-script-provider-bsh pn libreoffice-script-provider-js pn libreoffice-script-provider-python pn libreoffice-sdbc-postgresql pn libreoffice-wiki-publisher Versions of packages libreoffice suggests: ii cups-bsd 2.2.1-8+deb9u2 ii default-jre [java6-runtime]2:1.8-58 ii firefox-esr60.2.0esr-1~deb9u2 ii ghostscript9.20~dfsg-3.2+deb9u5 ii gnupg 2.1.18-8~deb9u2 pn gpa ii gstreamer1.0-libav 1.10.4-1 pn gstreamer1.0-plugins-bad ii gstreamer1.0-plugins-base 1.10.4-1 ii gstreamer1.0-plugins-good 1.10.4-1 ii gstreamer1.0-plugins-ugly 1.10.4-1 ii hunspell-en-ca [hunspell-dictionary] 1:5.2.5-1 ii hyphen-ca [hyphen-hyphenation-patterns]1:5.2.5-1 ii imagemagick8:6.9.7.4+dfsg-11+deb9u5 ii imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-11+deb9u5 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libreoffice-gnome 1:6.1.1~rc1-2~bpo9+1 pn libreoffice-help pn libreoffice-l10n ii libreoffice-lightproof-en [libreoffice-grammarche 0.4.3+1.5+git20140515-2 pn libreoffice-officebean ii libsane1.0.25-4.1 ii libxrender11:0.9.10-1 pn myspell-dictionary pn mythes-thesaurus ii openclipart-libreoffice1:0.18+dfsg-14 ii openjdk-8-jre [java6-runtime] 8u181-b13-1~deb9u1 ii pstoedit
Bug#909117: RFS: libmd5-rfc/0.0+20020413-1 [ITP]
Adam Borowski 于2018年9月19日周三 上午3:22写道： > > But, with md5 thoroughly broken, do you have any reason to include this > library? It's unfit for cryptographic purposes, and there exist much faster > hashes for non-crypto uses. Actually https://codesearch.debian.net/search?q=typedef+unsigned+int+md5_word_t But, if you think bundling is fine, I won't insist on pushing this package.
Bug#904558: What should happen when maintscripts fail to restart a service
Ian Jackson wrote: >> I personally think that it would make sense for the policy to at least >> recommend what should happen with regards to maintainer scripts and >> typical operations that are performed in them. > > There is already a section on error handling in scripts, which (IMO > correctly) says that shell scripts should use set -e. > > When I wrote that, it didn't occur to me that anyone would think that > a failure by a postinst script to perform an intended operation should > be treated any other way than a failure of the postinst script. That was perhaps also written before we started to realise that maintainer scripts are actually best avoided as they tend to be complicated, fragile, difficult to do right and make upgrades harder for the package manager. In the intervening two decades, we've gone from "maintainer scripts are cool" to "the best maintainer script is the one that doesn't exist". So yes, ignoring errors seems wrong but… >> And, while I'm open to be convinced otherwise, I don't see any benefit >> from postinst (particularly postinst + configure) ever failing. > > Frankly I'm disturbed to be reading this, here. See above. > > If the postinst fails, then the user has the opportunity to fix the > root cause and rerun dpkg-source --configure --pending. That will > then repair the system completely. … causing a snowball of errors in an awkward half-upgraded environment is nasty. The problem comes when you don't yet have the right tools installed to be able to fix the problem. We see that scenario often enough in #debian where someone has a failed upgrade and we try to collect more information via pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover that the relevant tool isn't installed and because apt is sufficiently unhappy about broken packages and a half-completed upgrade, you can't ask it to install the tool at that point in time. In the upgrade scenario, while you're trying to fix one particular problem, you're also in a completely untested half-upgraded situation and so latent bugs in any number of other tools may also be exposed. So while ignoring errors is wrong, so is making it harder to fix them. This isn't a question of absolutes. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars
These three show as boxes in xterm. T> (0x1f618, "FACE THROWING A KISS"); T> (0x7522, "CJK UNIFIED IDEOGRAPH-7522"); T> (0x9109, "CJK UNIFIED IDEOGRAPH-9109"); Yes, copying them from xterm to elsewhere reveals them.
Bug#855416: check_running_kernel: don't search /boot/lost+found
Package: nagios-plugins-contrib Version: 21.20170222 Hello, I run into the same problem. The proposed solution works for me. Sorry for asking, since I am a newbie: Is there any reason, that the patch was not accepted yes? Greetings Konrad
Bug#909114: [PATCH] Have V07pcre fail if PCRE was enabled by configure (config.modules) but failed to load for any reason.
From: Daniel Shahaf --- Test/V07pcre.ztst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Test/V07pcre.ztst b/Test/V07pcre.ztst index 9feeb47fb..ab67f3d80 100644 --- a/Test/V07pcre.ztst +++ b/Test/V07pcre.ztst @@ -1,11 +1,10 @@ %prep - if ! zmodload -F zsh/pcre C:pcre-match 2>/dev/null + if grep '^name=zsh/pcre .* link=no ' $ZTST_testdir/../config.modules >/dev/null then -ZTST_unimplemented="the zsh/pcre module is not available" +ZTST_unimplemented="the zsh/pcre module was disabled by configure (see config.modules)" return 0 fi -# Load the rest of the builtins zmodload zsh/pcre setopt rematch_pcre # Find a UTF-8 locale.
Bug#909114: [Pkg-zsh-devel] Bug#909114: Bug#909114: Bug#909114: Bug#909114: Check for missing pcre module
Control: tags -1 upstream Axel Beckert wrote on Wed, Sep 19, 2018 at 00:48:42 +0200: > Hi Daniel, > > Daniel Shahaf wrote: > > I came up with this, but when I applied it to 5.6.2-2 the build didn't fail > > as > > I expected it to. Does anyone see the problem? > > > > [[[ > > diff --git a/Test/V07pcre.ztst b/Test/V07pcre.ztst > > index 9feeb47fb..ab67f3d80 100644 > > --- a/Test/V07pcre.ztst > > +++ b/Test/V07pcre.ztst > > @@ -1,11 +1,10 @@ > > %prep > > > > - if ! zmodload -F zsh/pcre C:pcre-match 2>/dev/null > > + if grep '^name=zsh/pcre .* link=no ' $ZTST_testdir/../config.modules > > >/dev/null > > > Maybe because we build out of tree: > > ~/zsh/zsh → find . -name config.modules > ./obj-static/config.modules > ./obj/config.modules I don't think that's it. One, $ZTST_testdir/../Src/zsh is used all over the place to refer to the just-built zsh binary, so $ZTST_testdir/../ must be the build tree. Two, I did test it in my normal, static, out-of-tree build, and it behaved as expected. However, when I applied it to 5.6.2-2 (from 'apt-get source', not git) and rebuilt, the build passed. Oh! I see. What must have happened is: configure failed to detect libpcre, so it set link=no config.modules, so the grep matched and the test skipped. In other words, the test skipped (and therefore the build passed) because we haven't done the corresponding configure.ac fix. I'll send the V07 patch upstream. Shall we leave this bug open to track the autoconf work that needs doing? (That work, too, is upstreamable; tagging accordingly.) Cheers, Daniel
Bug#909151: 'Uncaught TypeError: nextTick is not a function' with node-process-nextick-args 2.0.0
Package: node-cloneable-readable Version: 1.0.0-1 Tags: patch node-cloneable-readable 1.0.0-1 needs an update for the newer node-process-nextick-args 2.0.0, which is now present in Debian sid and Ubuntu Cosmic. This can be verified in node-gulp's autotests: $ sudo apt-get build-dep node-gulp $ apt-get source node-gulp $ cd node-gulp-* Before: -- $ dpkg -s node-cloneable-readable | grep Version: Version: 1.0.0-1 $ debian/rules override_dh_auto_test ... 24 passing (164ms) 5 pending 2 failing 1) gulp output stream dest() should return a output stream that writes streaming files: Uncaught TypeError: nextTick is not a function ... 2) gulp input stream src() should return a input stream with contents as stream when buffer is false: Uncaught TypeError: nextTick is not a function ... make: *** [debian/rules:15: override_dh_auto_test] Error 2 $ echo $? 2 After: - $ dpkg -s node-cloneable-readable | grep Version: Version: 1.0.0-1ubuntu1 $ debian/rules override_dh_auto_test ... 26 passing (166ms) 5 pending $ echo $? 0 -- Mauricio Faria de Oliveira debian-node-cloneable-readable_nextick2.debdiff Description: Binary data
Bug#909114: [Pkg-zsh-devel] Bug#909114: Bug#909114: Bug#909114: Check for missing pcre module
Hi Daniel, Daniel Shahaf wrote: > I came up with this, but when I applied it to 5.6.2-2 the build didn't fail as > I expected it to. Does anyone see the problem? > > [[[ > diff --git a/Test/V07pcre.ztst b/Test/V07pcre.ztst > index 9feeb47fb..ab67f3d80 100644 > --- a/Test/V07pcre.ztst > +++ b/Test/V07pcre.ztst > @@ -1,11 +1,10 @@ > %prep > > - if ! zmodload -F zsh/pcre C:pcre-match 2>/dev/null > + if grep '^name=zsh/pcre .* link=no ' $ZTST_testdir/../config.modules > >/dev/null Maybe because we build out of tree: ~/zsh/zsh → find . -name config.modules ./obj-static/config.modules ./obj/config.modules Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#909142: Addition to bug, its not first highlighted wireless net, its any net which was configured with passphrase
Hello, I forgot to say thank you. Your fast response was unexpected! To add: ipv6 is disabled (sysctl) and network-manager is disabled as a service (systemd) and is not running If that makes any difference On 9/18/18, Axel Beckert wrote: > Control: tag -1 - moreinfo > > Hi Greg, > > Greg Masters wrote: >> I have to revise this a little. It appears my report about the bug in >> relation to the first wireless net was wrong. It happens when >> right-arrow any net **with** a changed config, like the addition of a >> wpa passphrase. In my last post the net with the changed config file >> contained the passphrase. BTW i deleted all configs (*.conf) in >> /etc/wicd and started over, with no change. >> >> The (P) prefs option to always show wirred nets is in unselected. >> >> Here is the trace as requested: > > Thanks for the additional details! > > Regards, Axel > -- > ,''`. | Axel Beckert , https://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 > `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE >
Bug#874683: Bug#875058: [mumble] Future Qt4 removal from Buster
Georg Faerber: > Hi all, > > It's been a year since the last update. > Therefore: Any news? > > Cheers, > Georg The good news: I've almost got a Mumble 1.3 snapshot ready for upload to Experimental, and I've [finally] figured out how to strip out the unreasable files from the upstream tarball in an automated way using the debian/copyright file and the debian/watch file used by uscan. With recent packaging work the Mumble 1.3 snapshots would successfully build but then the resulting Mumble client would fail to connect to servers due to Qt5 related SSL errors; however that got fixed 7 days ago with the upload of qtbase-opensource-src-5.11.1+dfsg-8. The bad news: Having to strip out files from the upstream tarball breaks the PGP signature, so I've had to remove the PGP signature check for now. I've informed Mumble upstream about the unrelasable files again [they're draft IETF documents that are part of Git submodules for Speex, CELT, and Opus], and they agree that it's an issue. Mumble upstream development has slowed, the main developers are out of contact, and the Windows build infrastructure has been down for some time [several weeks]. I suspect a Mumble 1.3 stable release will not be ready in time for the upcoming release of Buster. This worries me a bit when it comes to what the right thing to do for both Debian and Tails concerning Mumble. Let me know if there are suggestions re: dealing with this concerning Tails. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#574335: [pkg-ntp-maintainers] Bug#574335: ntpd shouldn't be started automatically
On Tue, Sep 18, 2018 at 11:44:29PM +0200, Bernhard Schmidt wrote: > > I have no idea how we can properly avoid that. When do you think > > would be a good time to reset the clock? After a reboot? I think > > it's not very obvious that you'd have to start it manually or > > reboot it after installation. > > I think ntp being started at installation and stepping the clock is the > most expected. Closing. Also, applications that can not handle steps should get fixed.
Bug#906375: libitext5-java: FTBFS in buster/sid (method marshal in class org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature cannot be applied to given types)
Hi, * Emmanuel Bourg [2018-08-29 11:51]: On 28/08/2018 21:31, Jochen Sprickerhof wrote: As a quick fix we could probably hack around the visibility modifiers of Marshaller, but I guess that would be rather ugly. Just mentioning it for completeness. +1 for adjusting the xml-security API. I opened merge requests for this: https://salsa.debian.org/java-team/libxml-security-java/merge_requests/1 https://salsa.debian.org/java-team/libitext5-java/merge_requests/1 Note that the new libitext5 version has runtime errors still, but I have patches for the current Debian version to at lest fix this RC: https://salsa.debian.org/jspricke/libitext5-java/tree/5.5.6 Would be great if one of you could review them. Cheers Jochen signature.asc Description: PGP signature
Bug#909150: glib2.0: intermittent FTBFS on armel: mainloop-test: segmentation fault
Source: glib2.0
Version: 2.58.0-4
Severity: important
glib2.0 2.58.0-4 failed to build on the armel buildd:
https://buildd.debian.org/status/fetch.php?pkg=glib2.0=armel=2.58.0-4=1537225902=0
> FAIL mainloop-test (exit status: 139)
(That's a segmentation fault, with no other output.)
I was able to reproduce this failure on the armel porterbox, abel, by
doing a build (which succeeded) and then running:
bash -euc 'for i in `seq 1 1000`; do time debian/build/deb/tests/mainloop-test;
done'
You can in fact also run this test as an installed binary without needing
to build it: it's /usr/lib/glib2.0/installed-tests/glib/mainloop-test
in the libglib2.0-tests package.
On my 81st attempt on abel, the test segfaulted.
% debian/build/deb/libtool --mode=execute gdb
debian/build/deb/tests/mainloop-test core
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00459634 in cleanup_crawlers (context=0xb5101218) at
../../../../tests/mainloop-test.c:364
364 if (g_source_get_context (crawler_array->pdata[i]) == context)
[Current thread is 1 (Thread 0xb5afe460 (LWP 29988))]
(gdb) thread apply all bt
Thread 2 (Thread 0xb6f503e0 (LWP 29972)):
#0 0xb6d2b750 in ?? () from /lib/arm-linux-gnueabi/libc.so.6
#1 0x00459c8c in adder_callback (source=, condition=, data=0x0)
at ../../../../tests/mainloop-test.c:122
#2 0x0010 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 0xb5afe460 (LWP 29988)):
#0 0x00459634 in cleanup_crawlers (context=0xb5101218) at
../../../../tests/mainloop-test.c:364
#1 adder_thread (data=) at ../../../../tests/mainloop-test.c:192
#2 0xb6e87628 in g_thread_proxy (data=0x2416c60) at
../../../../glib/gthread.c:784
#3 0xb6c1f1ac in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0
#4 0xb6d96ca8 in ?? () from /lib/arm-linux-gnueabi/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
(gdb) p *crawler_array
$1 = {pdata = 0x2415178, len = 0}
(gdb) p i
$2 = 0
(gdb) p (GSource *) crawler_array->pdata[0]
$5 = (GSource *) 0x2415190
(gdb) p *(GSource *) crawler_array->pdata[0]
$6 = {callback_data = 0x2415160, callback_funcs = 0x0, source_funcs =
0x, ref_count = 4294967295,
context = 0x0, priority = 0, flags = 37835528, source_id = 0, poll_fds =
0xb78731fa, prev = 0x182, next = 0x0,
name = 0x0, priv = 0x0}
(gdb) p *context
$8 = {mutex = {p = 0x0, i = {0, 0}}, cond = {p = 0x0, i = {1, 0}}, owner = 0x0,
owner_count = 0, waiters = 0x0,
ref_count = 1, sources = 0xb6302078, pending_dispatches = 0xb6302e50, timeout
= 1, next_id = 108,
source_lists = 0xb6303790, in_check_or_prepare = 0, poll_records =
0xb6303740, n_poll_records = 1,
cached_poll_array = 0xb51030e8, cached_poll_array_size = 2, wakeup =
0xb6301160, wake_up_rec = {fd = 21,
events = 1, revents = 0}, poll_changed = 1, poll_func = 0xb6e6cc78
, time = 1660937509354,
time_is_fresh = 1}
I'm not sure what is going on here; the stack traces don't look complete.
The last functional change to this test was in 2013.
smcv
Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs
Hey Antoine, Package ready for testing from: dget -x https://mentors.debian.net/debian/pool/main/m/markdown-toc-el/markdown-toc-el_0.1.2-1.dsc Upstream included an autoload cookie so 'markdown-toc-generate-toc' works out of the box. I can provide a deb and signed changes if that would be more convenient. In particular someone needs to test 'markdown-toc-user-toc-structure-manipulation-fn' before I can responsibly file an RFS bug. Cheers, Nicholas signature.asc Description: PGP signature
Bug#909023: works between two 6.20180913-1 repos
control: forwarded -1 https://git-annex.branchable.com/todo/Error_when_using_6.20180913_with_6.20170101-1+deb9u2/ Hello, On Tue 18 Sep 2018 at 05:16PM +0200, Marco wrote: > I tried with two clean repositories, one bare and one > non-bare. Initially the bare one was from stretch (6.20170101-1+deb9u2) > and the other from testing (6.20180913-1), the issue sowed up. Then I > upgraded the bare one from stretch/backports (6.20180913-1~bpo9+1) > nd... it worked! > > So I guess this is just a backward compatibility issue, would be nice to > know if there's any chance to fix it or else I'm going to move my > central repo on some other machine on which I can keep git-annex more up > to date. Oh, I replied without seeing this second e-mail. Thank you for the additional information. I have forwarded this report upstream for consideration. -- Sean Whitton signature.asc Description: PGP signature
Bug#909142: Addition to bug, its not first highlighted wireless net, its any net which was configured with passphrase
Control: tag -1 - moreinfo Hi Greg, Greg Masters wrote: > I have to revise this a little. It appears my report about the bug in > relation to the first wireless net was wrong. It happens when > right-arrow any net **with** a changed config, like the addition of a > wpa passphrase. In my last post the net with the changed config file > contained the passphrase. BTW i deleted all configs (*.conf) in > /etc/wicd and started over, with no change. > > The (P) prefs option to always show wirred nets is in unselected. > > Here is the trace as requested: Thanks for the additional details! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#909023: git-annex: fail to copy file contents
control: severity -1 important Dear Marco, On Mon 17 Sep 2018 at 04:39PM +0200, Marco Pattaro wrote: > in short: after upgrading to version 6.20180913-1 I'm unable to sync file > contents. > > My layout is a central bare repository on a machine which runs an older > version > of git-annex (6.20160923-1) and anumber of client, direct, repositories all up > to date with the latest debian testing release. All repositories have > [annex] > version = 5 > > in their .git/config > > After upgrading it fails to do any of: > > $ git annex sync --content > or > $ git annex get > or > $ git annex copy > > with this error message: "fd:23: hClose: resource vanished (Broken pipe)" > > I'm pretty sure the issue is not in my ssh connection whish is working > properly > in other contexts, nor in git because the file index is synced correctly. > > Could this be an incompatibility between git-annex versions? It could be. Could you provide steps to reproduce, please? I.e. please try to reproduce the bug using a fresh repository and tell me exactly what you did. Then I will try to replicate the problem. I am downgrading the severity of the bug because while backwards compatibility is desirable, the lack of it does not render the package useless. -- Sean Whitton signature.asc Description: PGP signature
Bug#908933: debian-policy: typo in document in section 3.4 page no 15 line number 16 needs improvement.
Dear Jaikumar, On Mon 17 Sep 2018 at 07:31PM +0530, Jaikumar Sharma wrote: > I took screen capture of the particular area of the document as > attached jpg image which i called inconsistent or odd looking, that > does not provide enough information to highlight what i called odd > and/or inconsistent? Sorry, it was last two characters (not three) > which looks a bit seperated from the rest of the word , do not you > think this is odd looking? :) > One more try. please see attached the screen capture again. Assuming you're talking about 'administrivia', I'm afraid that I still cannot see the problem. It looks normal to me. -- Sean Whitton signature.asc Description: PGP signature
Bug#909142: Addition to bug, its not first highlighted wireless net, its any net which was configured with passphrase
I have to revise this a little. It appears my report about the bug in relation to the first wireless net was wrong. It happens when right-arrow any net **with** a changed config, like the addition of a wpa passphrase. In my last post the net with the changed config file contained the passphrase. BTW i deleted all configs (*.conf) in /etc/wicd and started over, with no change. The (P) prefs option to always show wirred nets is in unselected. Here is the trace as requested: Traceback (most recent call last): File "/usr/share/wicd/curses/wicd-curses.py", line 1149, in call_update_ui self.update_ui(True) File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper return func(*args, **kargs) File "/usr/share/wicd/curses/wicd-curses.py", line 1162, in update_ui self.handle_keys(input_data) File "/usr/share/wicd/curses/wicd-curses.py", line 1040, in handle_keys self.diag = WirelessSettingsDialog(pos, self.frame) File "/usr/share/wicd/curses/netentry_curses.py", line 503, in __init__ self.set_values() File "/usr/share/wicd/curses/netentry_curses.py", line 544, in set_values wireless.GetWirelessProperty(networkID, 'bitrate') ValueError: dbus.Boolean(True) is not in list root@orangepizeroplus:~#
Bug#909149: libcwd: Please package new upstream version
Package: libcwd Severity: important Version: 1.0.4-1.1 X-Debbugs-CC: ca...@alinoe.com m...@qa.debian.org Dear Carlo, I noticed that you are listed as the maintainer of package libcwd in Debian. Thank you for your previous contribution. However, this package hasn't receive any upload since 2010 and that this package has new upstream version that fixes the bugs. I am wondering if you are still able to make uploads and fix those bugs recently (ideally before Buster release); if that is not possible, please feel free to tell me so that this package can be properly dealt and maintained inside Debian. If there's no reply in the following 31 days, I might consider making a non- maintainer upload to fix the bugs. Sending mail copy to Debian QA/MIA Team to get the team involved. Thank you very much, -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#909148: [kid3] QML debugging is enabled
Package: kid3 Version: 3.6.2-1 Severity: important Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org --- Please enter the report below this line. --- Running kid3-cli or kid-qt I get the warning: QML debugging is enabled. Only use this in a safe environment.
Bug#909105: consider switching asciidoctor to Architecture: all
> I reported that bug. Indeed, that's why I was confused! :D > After reading my report three times, I see how you > might have interpreted it that way. I wrote that there is a problem, > "because asciidoctor is Architecture: all and implicitly Multi-Arch: > no". The problem results from the combination of those fields, not from > either single field. The satisfiability problem is fully solved by the > Multi-Arch: foreign field alone regardless of the Architecture value. After reviewing the change, I don't exactly remember why I did the change only on the ruby-asciidoctor package but I'm guessing I simply forgot to update asciidoctor arch part when doing the split. I'll have a look at it asap. Joseph
Bug#909142: wicd-curses: Right-arrow on first wlan errors wicd-curses.py
Control: tag -1 + moreinfo Hi Greg, Greg Masters wrote: > Version: 1.7.4+tb2-6 JFTR: That's the version currently in unstable. > I am working with the newest version of wicd-curses installed from .deb > manually using dpkg. I installed wicd_1.7.4+tb2-6all.deb, and wicd-curses, > python-wicd, wicd-daemon all of the same version number. According to the System Information you are working on Debian Stretch. That combination is not really supported. > The latest are not in the repos. They are in the unstable and testing repos. > They supposedly fixed similar errors as in debian > bug 816597. Yes. That bug report was a duplicate of #814090. > This errors flag lines 97, 1149, 1162, 1040 in > /usr/share/wicd/wicd-curses-py. > And file /usr/share/wicd/curses/netentry_curses.py, line 503 and 544. Please post the full backtrace you're getting. (At least if I can't reproduce this quickly.) > Last line after crash is ValueError: dbus.Boolean(True) is not in list > > On invoking wicd-curses, any attempt to right-arrow on the FIRST > LISTED wireless net will crash. Do you have "always show wired network" on or off? I usually have it on, so that case might have slipped through since it might only happen if that setting is set to "off". > If the highlight bar is moved (down arrow) to the second or third > wireless net, then right-arrow brings up the config screen as > expected. Ok, will check if I can reproduce this issue on Debian Unstable, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#909147: gawk: Usage of \ in gensub doesn't match documentation
Package: gawk
Version: 1:4.1.4+dfsg-1
Severity: normal
Hello,
https://www.gnu.org/software/gawk/manual/html_node/Gory-Details.html#Gory-Details
states:
At the runtime level, whenever gawk sees a ‘\’ [in the
replacement text], if the following character is a digit, then
the text that matched the corresponding parenthesized
subexpression is placed in the generated output. Otherwise, no
matter what character follows the ‘\’, it appears in the
generated text and the ‘\’ does not [...].
this however isn't true when there are several backslashes:
uwe@taurus:~$ echo 'a' | awk '{ gsub("a", ""); print }'
\\
uwe@taurus:~$ echo 'a' | awk '{ gsub("a", "\\"); print }'
\\\
uwe@taurus:~$ echo 'a' | awk '{ gsub("a", ""); print }'
\\
The first two instances are still ok, but in the third I expect four
backslashes, not two. With GNU Awk 4.0.2 (found on a Centos 7 machine) I get
actually four; with gawk 1:4.2.1+dfsg-1 from sid there are also only two.
When I pass n backslashes as replacement text it seems to output
2 * (n // 8) + (n % 8) / 2
backslashes instead of
n // 2
(where "//" is integer division).
Best regards
Uwe
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'),
(500, 'stable'), (499, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gawk depends on:
ii libc6 2.27-6
ii libgmp10 2:6.1.2+dfsg-3
ii libmpfr6 4.0.1-1
ii libreadline7 7.0-5
ii libsigsegv2 2.12-2
gawk recommends no packages.
Versions of packages gawk suggests:
pn gawk-doc
-- no debconf information
Bug#909146: open-vm-tools guest stats overflow
Package: open-vm-tools Version: 2:10.3.0-1 There is an unhandled overflow issue in open-vm-tools in the code for guest stats reporting. This cause artifacts (spikes) in rate stats, for example "Guest|Page In Rate per second". This issue only affects 32 bit builds of open-vm-tools. We have a fix for 10.3.x at https://github.com/vmware/open-vm-tools/commit/c7a186e204cdff46b5e02bcb5208ef8979eaf261 The fix has also been backported to 10.2.5 in a special branch: https://github.com/vmware/open-vm-tools/tree/stable-10.2.5-stat-overflow-fix Thanks, Oliver
Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure
Le 15/09/2018 à 17:42, Damyan Ivanov a écrit :
> -=| gregor herrmann, 14.09.2018 16:08:50 +0200 |=-
>> Control: tag -1 + unreproducible
>>
>> On Fri, 14 Sep 2018 16:52:38 +0300, Adrian Bunk wrote:
>>
>>> Source: libnet-server-mail-perl
>>> Version: 0.25-1
>>> Severity: serious
>>> Tags: ftbfs
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=libnet-server-mail-perl=all=0.25-1=1536904015=0
>>
>> Thanks for the bug report.
>>
>>> ...
>>> Test Summary Report
>>> ---
>>> t/starttls.t (Wstat: 9 Tests: 3 Failed: 0)
>>> Non-zero wait status: 9
>>> Parse errors: No plan found in TAP output
>>> Files=4, Tests=33, 2 wallclock secs ( 0.05 usr 0.04 sys + 0.67 cusr
>>> 0.20 csys = 0.96 CPU)
>>> Result: FAIL
>>> Failed 1/4 test programs. 0/33 subtests failed.
>>> make[1]: *** [Makefile:861: test_dynamic] Error 255
>>
>> Hm, the package builds for me.
>>
>>
>> The buildd failure is:
>>
>> # Error: TLS handshake failed SSL connect attempt failed at t/starttls.t
>> line 116.
>> # kill 9, 17145 (server)
>> t/starttls.t ..
>> ok 1 - Accepted client for Test01: STARTTLS support
>> ok 2 - Accepted client for Test02: STARTTLS invalid parameters
>> ok 3 - Accepted client for Test03: STARTTLS handshake
>> All 3 subtests passed
>>
>>
>> Line 116 in the test is:
>>
>>112 my $rv =
>>113 IO::Socket::SSL->start_SSL( $s,
>>114 SSL_verify_mode =>
>> IO::Socket::SSL::SSL_VERIFY_NONE, );
>>115
>>116 ( defined $rv && ref $rv eq 'IO::Socket::SSL' )
>>117 or die "TLS handshake failed >" .
>> IO::Socket::SSL::errstr();
>
>
> Building the package several times (sbuild) passes here most of the
> time and then:
>
> # Error: Can't call method "peerhost" on an undefined value at t/starttls.t
> line
> 131.
> # kill 9, 28330 (server)
> t/starttls.t ..
> ok 1 - Accepted client for Test01: STARTTLS support
> ok 2 - Accepted client for Test02: STARTTLS invalid parameters
> ok 3 - Accepted client for Test03: STARTTLS handshake
> All 3 subtests passed
>
> Adding
> $SIG{PIPE} = 'IGNORE';
> at the start of the test seems to make it pass all the time.
>
> I wonder if this is the correct fix.
>
> -- Damyan
Hello,
I added this hook without success. "reproducible" builds well [1] but
not buildd [2]
[1]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnet-server-mail-perl.html)
[2] https://buildd.debian.org/status/package.php?p=libnet-server-mail-perl
Bug#840742: RFP: golang-github-kardianos-service -- Run go programs as a service on major platforms
Hi! On Fri, 2016-10-14 at 13:45:40 +0200, Guillem Jover wrote: > Package: wnpp > Severity: wishlist > Tags: patch > Control: block 793749 by -1 > > * Package name: golang-github-kardianos-service > Version : 0.0~git20160824.0.7a88211-1 > Upstream Author : Daniel Theophanes > * URL : https://github.com/kardianos/service > * License : zlib > Programming Lang: Go > Description : Run go programs as a service on major platforms > > service will install / un-install, start / stop, and run a program as a > service (daemon). Currently supports Linux/(systemd | Upstart | SysV), > OSX/Launchd and Windows XP+. > . > Windows controls services by setting up callbacks that are non-trivial. This > is very different than other systems. This package provides the same API > despite the substantial differences. It also can be used to detect how a > program is called, from an interactive terminal or from a service manager. > Attached a working and tested packaging, where only the ITP bug number > needs to be filled in the debian/changelog, Maintainer changed, and Vcs > fields added. Attached updated packaging to current standards. Thanks, Guillem golang-github-kardianos-service_0.0~git20160824.0.7a88211-0.1.debian.tar.xz Description: application/xz
Bug#909145: maxima-share: load(draw) compilation error
Package: maxima-share Version: 5.38.1-8 Severity: important Dear Maintainer, Installing maxima and maxima-share, then loading the draw package in a new maxima session should result in maxima compiling the draw package from source. However, the compilation errors out because gcl is not installed. Installing gcl fixes the issue. $ maxima Maxima 5.38.1 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.12 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) load(draw); Compiling /usr/share/maxima/5.38.1/share/draw/grcommon.lisp. End of Pass 1. End of Pass 2. execvp failure when executing '/usr/bin/gcc -c -g -fdebug-prefix-map=/home/camm/gcl-2.6.12=. -fstack-protector-strong -Wformat -Werror=format-security -fsigned-char -pipe -fno-builtin-malloc -fno-builtin-free -fno-PIE -fno-pie -fno-PIC -fno-pic -Wall -Wno-empty-body -Wno-unused-but-set-variable -Wno-misleading-indentation -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/lib/gcl-2.6.12/unixport/../h -O2 -c /home/leobutler/.maxima/binary/5_38_1/gcl/GCL_2_6_12/share/draw/grcommon.c -o /home/leobutler/.maxima/binary/5_38_1/gcl/GCL_2_6_12/share/draw/grcommon.o ': No such file or directory loadfile: failed to load /usr/share/maxima/5.38.1/share/draw/draw.lisp -- an error. To debug this try: debugmode(true); (%i2) -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages maxima-share depends on: ii maxima 5.38.1-8+b1 ii tex-common 6.06 maxima-share recommends no packages. maxima-share suggests no packages. -- no debconf information
Bug#904558: What should happen when maintscripts fail to restart a service
]] Ian Jackson Hi, > There may be good reasons not to treat daemon startup failure as a > postinst failure, but the argument above is not one of them. I think this is the core question. I largely agree with Ian here that having postinsts fail is not that big a deal if they can't make forward progress, but also we're being asked to advice on what happens when a maintainer script fails to restart a service. I disagree with him on whether failure to start/restart a service should be considered a configuration failure. The API provided by a package being in the configured state is not whether the relevant daemon is running or not; that is runtime and can and will change many times while the package is in the configured state, so dpkg dependencies are not useful for expressing «this service must be running». (There's also the case where the service is running on a separate host, which is often the case for services such as databases and where the use of Depends is inappropriate.) I think the general rule should be that the success/failure of the postinst script should signal whether the package considers itself ready to provide whatever API it exists to provide (disregarding the case of Essential packages here, since those are special). This means that failure to start a daemon should generally not cause the postinst to fail. At the same time, I think there are exceptions to this rule that should be left to maintainer judgement: sshd comes to mind as a service where if it can't restart, you want the system to make it very clear that something is wrong that you might want to fix sooner rather than later (since failure to do so can lead to you not being able to access it after a reboot). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#909144: RFP: golang-github-tidwall-gjson -- JSON Parser for Go
Package: wnpp Severity: wishlist Tags: patch Control: block 793749 by -1 * Package name: golang-github-tidwall-gjson Version : 1.1.3-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/gjson * License : Expat Programming Lang: Go Description : JSON Parser for Go Go package that provides a fast and simple way to get values from a json document. It has features such as one line retrieval , dot notation paths, iteration, and parsing json lines. This package is a dependency of the latest telegraf upstream release. Attached a working and tested packaging, where only the ITP bug number needs to be filled in the debian/changelog, and Maintainer changed. Thanks, Guillem golang-github-tidwall-gjson_1.1.3-0.1.debian.tar.xz Description: application/xz
Bug#783011: Skip /etc/awstats/awstats.conf if it's not configured
I too must admit that it's quite confusing to get error mails after 'sudo apt-get install awstats' (7.6+dfsg-2). Maybe it would be better to simply set AWSTATS_ENABLE_BUILDSTATICPAGES and AWSTATS_ENABLE_CRONTABS in /etc/default/awstats to "no" by default.
Bug#909143: RFP: golang-github-tidwall-match -- simple string pattern matcher for Go
Package: wnpp Severity: wishlist Tags: patch Control: block 793749 by -1 * Package name: golang-github-tidwall-match Version : 0.0~git20171002.1731857-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/match * License : Expat Programming Lang: Go Description : simple string pattern matcher for Go Match is a very simple pattern matcher where '*' matches on any number characters and '?' matches on any one character. This package is a dependency of the latest telegraf upstream release. Attached a working and tested packaging, where only the ITP bug number needs to be filled in the debian/changelog, and Maintainer changed. Thanks, Guillem golang-github-tidwall-match_0.0~git20171002.1731857-0.1.debian.tar.xz Description: application/xz
Bug#909142: wicd-curses: Right-arrow on first wlan errors wicd-curses.py
Package: wicd-curses Version: 1.7.4+tb2-6 Severity: important Dear Maintainer, I am working with the newest version of wicd-curses installed from .deb manually using dpkg. I installed wicd_1.7.4+tb2-6all.deb, and wicd-curses, python-wicd, wicd-daemon all of the same version number. The latest are not in the repos. They supposedly fixed similar errors as in debian bug 816597. This errors flag lines 97, 1149, 1162, 1040 in /usr/share/wicd/wicd-curses-py. And file /usr/share/wicd/curses/netentry_curses.py, line 503 and 544. Last line after crash is ValueError: dbus.Boolean(True) is not in list On invoking wicd-curses, any attempt to right-arrow on the FIRST LISTED wireless net will crash. If the highlight bar is moved (down arrow) to the second or third wireless net, then right-arrow brings up the config screen as expected. Request: Fix the right-arrow behavior to be consisitent. Thank you -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armhf Kernel: Linux 4.14.65-sunxi64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wicd-curses depends on: ii python2.7.13-2 ii python-urwid 1.3.1-2+b1 ii wicd-daemon 1.7.4+tb2-6 Versions of packages wicd-curses recommends: ii sudo 1.8.19p1-2.1 wicd-curses suggests no packages. Versions of packages wicd depends on: ii wicd-daemon 1.7.4+tb2-6 Versions of packages wicd-cli depends on: ii python 2.7.13-2 ii wicd-daemon 1.7.4+tb2-6 Versions of packages wicd-cli recommends: ii sudo 1.8.19p1-2.1 Versions of packages wicd-gtk depends on: ii python 2.7.13-2 pn python-glade2 pn python-gtk2 ii wicd-daemon1.7.4+tb2-6 Versions of packages wicd-gtk recommends: ii policykit-10.105-18 pn python-notify Versions of packages wicd-daemon depends on: ii adduser 3.115 ii dbus 1.10.26-0+deb9u1 ii debconf 1.5.61 ii iputils-ping 3:20161105-1 ii isc-dhcp-client 4.3.5-3+deb9u1 ii lsb-base 9.20161125 ii psmisc22.21-2.1+b2 ii python2.7.13-2 ii python-dbus 1.2.4-1+b1 ii python-gobject-2 2.28.6-13 ii python-wicd 1.7.4+tb2-6 ii wireless-tools30~pre9-12+b1 ii wpasupplicant 2:2.4-1+deb9u1 Versions of packages wicd-daemon recommends: ii rfkill 0.5-1+b1 Versions of packages wicd-daemon suggests: pn pm-utils Versions of packages python-wicd depends on: ii net-tools 1.60+git20161116.90da8a0-1 ii python 2.7.13-2 Versions of packages python-wicd suggests: ii ethtool 1:4.8-1+b1 ii iproute2 4.9.0-1+deb9u1 -- debconf information: * wicd/users:
Bug#909141: RFP: golang-github-influxdata-go-syslog -- Go parser for syslog messages
Package: wnpp Severity: wishlist Tags: patch Control: block 793749 by -1 * Package name: golang-github-influxdata-go-syslog Version : 1.0.1-1 Upstream Author : InfluxData * URL : https://github.com/influxdata/go-syslog * License : Expat Programming Lang: Go Description : Go parser for syslog messages This package provides: • a RFC5424-compliant parser • a RFC5424-compliant builder • a RFC5425-compliant parser This package is a dependency of the latest telegraf upstream release. Attached a working and tested packaging, where only the ITP bug number needs to be filled in the debian/changelog, and Maintainer changed. Thanks, Guillem golang-github-influxdata-go-syslog_1.0.1-0.1.debian.tar.xz Description: application/xz
Bug#909139: i915 missing Switch to turn off rc6 causes Screen Flicker on idle y910
Package: i915 Version: firmware-misc-nonfree Severity: normal Dear Maintainer, * What led up to the situation? Since the update to kernel 4.16 I can't prevent my Lenovo Yoga 910 from having severe screen flicker when idle. * What exactly did you do (or not do) that was effective (or ineffective)? Booting with option i.915.enable_rc6=0 prevented the flicker from happening. * What was the outcome of this action? Since kernel 4.16 this does not work anymore. My research shows that the option in question is not included in the firmware anymore. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#858461: logrotate call in debian/README.Debian no more working
In addition to the advices in debian/README.Debian * change line in /etc/logrotate.d/apache2 to: "create 644 root adm" * change permissions of existing files: chmod 644 /var/log/apache2/*.log you also need "chmod 755 /var/log/apache2" to allow www-data to access the logs.
Bug#909140: python-marshmallow: CVE-2018-17175
Source: python-marshmallow Version: 3.0.0b3-1 Severity: important Tags: security upstream Forwarded: https://github.com/marshmallow-code/marshmallow/issues/772 Hi, The following vulnerability was published for python-marshmallow. CVE-2018-17175[0]: | In the marshmallow library before 2.15.1 and 3.x before 3.0.0b9 for | Python, the schema "only" option treats an empty list as implying no | "only" option, which allows a request that was intended to expose no | fields to instead expose all fields (if the schema is being filtered | dynamically using the "only" option, and there is a user role that | produces an empty value for "only"). If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-17175 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17175 [1] https://github.com/marshmallow-code/marshmallow/issues/772 [2] https://github.com/marshmallow-code/marshmallow/pull/777 [3] https://github.com/marshmallow-code/marshmallow/pull/782 Regards, Salvatore
Bug#909138: breeze-gtk: useless autopkgtest
Source: breeze-gtk Version: 5.13.5-1 breeze-gtk's autopkgtest only runs dh_auto_test. I believe the upstream source doesn't contain any tests, which means that dh_auto_test isn't really doing anything useful. Please consider dropping the autopkgtest. Similarly, I think you can drop the Build-Depends on xvfb and the dh_auto_test override. (Even though it doesn't do anything now, I don't think it's worth overriding.) Thanks, Jeremy Bicha
Bug#909137: RFP: golang-github-influxdata-tail -- Go package for reading from continuously updated files (tail -f)
Package: wnpp Severity: wishlist Tags: patch Control: block 793749 by -1 * Package name: golang-github-influxdata-tail Version : 1.0.0+git20180327.c434825-1 Upstream Author : InfluxData * URL : https://github.com/influxdata/tail * License : Expat Programming Lang: Go Description : Go package for reading from continuously updated files (tail -f) Description: Go package for reading from continuously updated files (tail -f) tail is a Go library striving to emulate the features of the BSD tail program (like tail -f). It comes with full support for truncation/move detection as it is designed to work with log rotation tools. This package is a required dependency for the latest telegraf upstream release. This is a fork of the golang-github-hpcloud-tail that got removed some time ago from the archive. Attached the initial packaging. It requires filling the ITP bug number, and setting proper Uploaders. Thanks, Guillem golang-github-influxdata-tail_1.0.0+git20180327.c434825-0.1.debian.tar.xz Description: application/xz
Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs
Control: tag -1 - moreinfo Control: retitle -1 ITP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs Control: owner -1 ! Hi Antoine, On Tue, Sep 18, 2018 at 09:44:19AM -0400, Antoine Beaupré wrote: > On 2018-09-17 22:40:10, Nicholas D Steeves wrote: > > > > Re: a couple of markdown-toc bugs: > > > > https://github.com/ardumont/markdown-toc/issues/29 > > * Solve in Debian with a hard depends on >= markdown-mode 2.2? > > * You mentioned markdown-mode 2.1 is bad, 20161222.1416 is good, > > and 2.2 is from 20170526, thus 2.2 should be good. > > * possibly fixed in markdown-toc? > > > > https://github.com/ardumont/markdown-toc/issues/15 > > * "Don't assume that a document has an h1" > > * How serious is this one? Seems like it could be annoying. > > > > https://github.com/ardumont/markdown-toc/issues/35 > > * "Lines starting with # in code sections are treated as headings" > > * I imagine this one will frustrate many users. > > I'm not sure how that's relevant to this RFP. Sure, like any other > software, markdown-toc has bugs. :) Those are not critical and the thing > generally works in my use cases. I think it can be packaged as is. Ok, will do! Yes, all software has bugs...when considering maintaining a pkg I ask myself "is this something will have to fix, and will a lot of people be unhappy if I don't?" vs "I've got a year's old back queue of stuff that's important to me". Thinking optimistically, maybe a Debian user will submit a patch for #15 and #35? ;-) > > By the way, if you'd like I'd be happy to give you an intro on dh-elpa > > packaging. With the exception of a couple of autopkgtest on LXC > > workarounds it's easy stuff--the trickiest bit is identifying why an > > upstream self-test doesn't work on buildd. Also, we're working on > > improving dh-elpa's documentation, so alternatively it would be nice > > to hear about your experiences with it--and than make improvements if > > necessary! dh_elpa(1), dh_elpa_test(1), dh-make-elpa(1), plus > > I'm sure you guys did a great job and it's nice to see so many ELPA > packages being added into Debian. Unfortunately, I don't have much time > to handle the packaging myself so if you do not mind I'll stay on this > side of the packaging for now. :) If I do find the time, you'll be the > first to know (here) that I can work on a package of course. Cool :-) Cheers, Nicholas signature.asc Description: PGP signature
Bug#874077: clutter-1.0: build tests fail on Debian but pass on Ubuntu
Control: reassign -1 src:xorg-server 2:1.20.1-1 I have an easier test case: libepoxy (since it builds a lot faster than clutter) [1]. The tests pass if I change the dh_auto_test override to xvfb-run -s "-screen 0 640x480x16" dh_auto_test Therefore, it looks like Debian needs to grab this commit: https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/ec812c8f74b4f [1] https://salsa.debian.org/debian/libepoxy Thanks, Jeremy Bicha
Bug#874077: clutter-1.0: build tests fail on Debian but pass on Ubuntu
Control: reassign src:xorg-server 2:1.20.1-1 Control: affects -1 src:clutter-1.0 I have an easier test case: libepoxy (since it builds a lot faster than clutter) [1]. The tests pass if I change the dh_auto_test override to xvfb-run -s "-screen 0 640x480x16" dh_auto_test Therefore, it looks like Debian needs to grab this commit: https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/ec812c8f74b4f [1] https://salsa.debian.org/debian/libepoxy Thanks, Jeremy Bicha
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
]] Philip Hands > Tollef Fog Heen writes: > > >This should be implemented in Debian Policy by declaring that a a >^^^ > You've this doubled 'a' on two occasions in this text. I'll fix that, thanks for spotting it. > Presumaly we would not want to see new packages adopting the use of > vendor-specific patch series prior to Buster. > > Do we need to make the "SHOULD NOT" conditional on the package already > having a vendor-specific patch series at the time of this resolution? I think that just adds needless complexity and assumes that maintainers will want to add bugs to their package. I really hope that's not the case, so I don't think it's worthwhile to add extra language for it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#592548: rubber-info gives "IndexError: list index out of range"
Control: tags -1 - unreproducible On 02.08.18 Nicolas Boulenguez (nico...@debian.org) wrote: Hi Nicolas, > Both files compile correctly with rubber/1.4-3. > The bug has probably been fixed since, I suggest to close it. > I guess the point is not the rubber run, but the rubber-info call. This issue I can still reproduce using rubber 1.5.1. Hilmar -- sigmentation fault signature.asc Description: PGP signature
Bug#909136: kicad: missing support for STEP export
Package: kicad Version: 5.0.0+dfsg1-2 Severity: wishlist Tags: patch The kicad package in Debian doesn't support exporting PCB into STEP-File, the option in the menu is disabled. This is because the kicad2step binary is not shipped in the package. However it is correctly built, so it's just a matter of updating the install file as follow: --- a/debian/kicad.install.in +++ b/debian/kicad.install.in @@ -13,6 +13,7 @@ usr/bin/idfcyl usr/bin/idfrect usr/bin/kicad +usr/bin/kicad2step usr/bin/pcb_calculator usr/bin/pcbnew usr/bin/pl_editor Would it be possible to do that in the next upload? Thanks, Aurelien -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kicad depends on: ii libc6 2.27-6 ii libcairo2 1.15.12-1 ii libcurl47.61.0-1 ii libfreeimage3 3.17.0+ds1-5+b5 ii libfreetype62.8.1-2 ii libgcc1 1:8.2.0-6 ii libgl1 1.1.0-1 ii libglew2.0 2.0.0-6 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libglx0 1.1.0-1 ii libgomp18.2.0-6 ii libice6 2:1.0.9-2 ii liboce-foundation11 0.18.2-3 ii liboce-modeling11 0.18.2-3 ii liboce-ocaf-lite11 0.18.2-3 ii liboce-ocaf11 0.18.2-3 ii liboce-visualization11 0.18.2-3 ii libopengl0 1.1.0-1 ii libpixman-1-0 0.34.0-2 ii libpython2.72.7.15-4 ii libsm6 2:1.2.2-1+b3 ii libssl1.1 1.1.0h-4 ii libstdc++6 8.2.0-6 ii libwxbase3.0-0v53.0.4+dfsg-4 ii libwxgtk3.0-0v5 3.0.4+dfsg-4 ii libx11-62:1.6.6-1 ii libxext62:1.3.3-1+b2 ii python 2.7.15-3 ii python-wxgtk3.0 3.0.2.0+dfsg-8 Versions of packages kicad recommends: ii kicad-demos 5.0.0+dfsg1-2 ii kicad-libraries 5.0.0+dfsg1-2 ii xsltproc 1.1.32-2 Versions of packages kicad suggests: ii extra-xdg-menus 1.0-4 pn kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad- ii kicad-packages3d5.0.0-2 -- no debconf information
Bug#909076: ghostscript: ps2ascii crashes: Error: /typecheck in --.bind--
hi, On Tue, Sep 18, 2018 at 09:58:10AM +0200, Mattia Rizzolo wrote: > Package: ghostscript > Version: 9.20~dfsg-3.2+deb9u5 > Severity: serious > X-Debbugs-CC: t...@security.debian.org, Moritz Mühlenhoff , > reproducible-bui...@lists.alioth.debian.org > Control: affects -1 diffoscope > > Dear maintainer, > > after the latest ghostscript security update, ps2ascii started to crash: > > |% ps2ascii > /build/diffoscope-101~bpo9+1/.pybuild/pythonX.Y_3.5/build/tests/data/test1.ps > |Error: /typecheck in --.bind-- > |Operand stack: > | --nostringval-- false setshared true --dict:30/32(L)-- > typecheck --nostringval-- currentglobal .currentglobal > |Execution stack: > | %interp_exit .runexec2 --nostringval-- --nostringval-- > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > --nostringval-- false 1 %stopped_push 1998 2 3 %oparray_pop > 1997 2 3 %oparray_pop 1981 2 3 %oparray_pop 1868 2 3 > %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- > --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- > 2009 3 3 %oparray_pop --nostringval-- --nostringval-- > --dict:1267/1684(G)-- --nostringval-- 1936 %dict_continue > --nostringval-- 1974 9 4 %oparray_pop --nostringval-- > |Dictionary stack: > | --dict:1267/1684(G)-- --dict:0/20(G)-- --dict:81/200(L)-- > --dict:1267/1684(G)-- > |Current allocation mode is global > |Current file position is 44643 > |GPL Ghostscript 9.20: Unrecoverable error, exit code 1 > > > Downgrading to 9.20~dfsg-3.2+deb9u4 shows the problem is limited to the > latest update: > > |% ps2ascii > /build/diffoscope-101~bpo9+1/.pybuild/pythonX.Y_3.5/build/tests/data/test1.ps > | > | > |Today's date: February 28, 2016 > | > |1 > > > This also causes diffoscope (both 78 in stretch and whatever is in > stretch-backports at the moment) to FTBFS. Some updates: The issue is triggered by the 025_fb713b3818b52d8a6cf62c951eba2e1795ff9624.patch patch, which is http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=fb713b3818b52d8a6cf62c951eba2e1795ff9624 . Ghostscript built from git on fb713b3818b52d8a6cf62c951eba2e1795ff9624 does not seem to tigger the same problem, so if this is correct, we might miss a prerequisite to fb713b3818b52d8a6cf62c951eba2e1795ff9624 . Regards, Salvatore
Bug#846614: RFP: golang-github-influxdata-wlog -- simple log level based Golang logger
Hi! On Fri, 2016-12-02 at 17:26:34 +0100, Guillem Jover wrote: > Package: wnpp > Severity: wishlist > Tags: patch > Control: block 793749 by -1 > > * Package name: golang-github-influxdata-wlog > Version : 0.0~git20160411.0.7c63b0a-1 > Upstream Author : InfluxData > * URL : https://github.com/influxdata/wlog > * License : MIT > Programming Lang: Go > Description : simple log level based Golang logger > > Provides an io.Writer that filters log messages based on a log level > prefix. Valid log levels are: DEBUG, INFO, WARN, ERROR, OFF. > > > This package is a dependency of the new telegraf 1.1.1 upstream release. > > Attached a working and tested packaging, where only the ITP bug number > needs to be filled in the debian/changelog, and Maintainer changed. Attached updated packaging. Thanks, Guillem golang-github-influxdata-wlog_0.0~git20160411.0.7c63b0a-0.1.debian.tar.xz Description: application/xz
Bug#909135: consider dropping python support from libtevent.a
Source: tevent Version: 0.9.36-2 Severity: wishlist Tags: patch User: helm...@debian.org Usertags: rebootstrap I tried cross building tevent and its Build-Depends turn out to be "difficult" to satisfy. So I looked why they exist and was very confused. When building tevent with --disable-python and then comparing the resulting packages using diffoscope, one can see that indeed there is a difference. Surprisingly, that difference is limited to the static libtevent.a. The shared library lacks Python support. Given that you cannot load a static library into a Python interpreter and that static linking is discouraged in Debian, it would seem that the use of Python support in a static library is quite limited. How about removing it by passing --disable-python? The resulting simplification of Build-Depends should bring us closer to cross building tevent. Helmut diff --minimal -Nru tevent-0.9.36/debian/changelog tevent-0.9.36/debian/changelog --- tevent-0.9.36/debian/changelog 2018-05-15 15:42:59.0 +0200 +++ tevent-0.9.36/debian/changelog 2018-09-18 21:10:58.0 +0200 @@ -1,3 +1,10 @@ +tevent (0.9.36-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop python support from the static library. (Closes: #-1) + + -- Helmut Grohne Tue, 18 Sep 2018 21:10:58 +0200 + tevent (0.9.36-2) unstable; urgency=low * Upload to unstable diff --minimal -Nru tevent-0.9.36/debian/control tevent-0.9.36/debian/control --- tevent-0.9.36/debian/control2018-03-11 20:53:12.0 +0100 +++ tevent-0.9.36/debian/control2018-09-18 21:10:58.0 +0200 @@ -8,8 +8,6 @@ libtalloc-dev (>= 2.1.11~), pkg-config, python, - python-all-dev (>= 2.6.6-3), - python-talloc-dev (>= 2.1.11~) Standards-Version: 4.1.3 Homepage: https://tevent.samba.org/ Vcs-Browser: https://salsa.debian.org/samba-team/tevent diff --minimal -Nru tevent-0.9.36/debian/rules tevent-0.9.36/debian/rules --- tevent-0.9.36/debian/rules 2018-03-11 20:41:47.0 +0100 +++ tevent-0.9.36/debian/rules 2018-09-18 21:10:58.0 +0200 @@ -19,7 +19,7 @@ override_dh_auto_configure: CFLAGS="$(CFLAGS)" ./configure --prefix=/usr --bundled-libraries=NONE \ - --disable-rpath --disable-rpath-install \ + --disable-rpath --disable-rpath-install --disable-python \ --minimum-library-version="$(shell ./debian/autodeps.py --minimum-library-version)" \ --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
Bug#901249: xterm: translation overrides for copy/paste do not work as documented
- Original Message - | From: "Thorsten Glaser" | To: "Thomas Dickey" | Cc: 901...@bugs.debian.org | Sent: Tuesday, September 18, 2018 2:56:26 PM | Subject: Bug#901249: xterm: translation overrides for copy/paste do not work as documented | Thomas Dickey dixit: | |>actually it was never intended that you could select both at the same |>time. In #336, I've disallowed that. | | What does that even mean, wrt. the bug report? The example you gave to show that the manual page was incorrect will no longer apply. -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Bug#874077: clutter-1.0: build tests fail on Debian but pass on Ubuntu
Control: reassign src:xorg-server 2:1.20.1-1 Control: affects -1 src:libepoxy src:clutter-1.0 Ok, I have an easier test case: libepoxy (since it builds a lot faster than clutter) [1]. The tests pass if I change the dh_auto_test override to xvfb-run -s "-screen 0 640x480x16" dh_auto_test Therefore, it looks like Debian needs to grab this commit: https://salsa.debian.org/xorg-team/xserver/xorg-server/commit/ec812c8f74b4f [1] https://salsa.debian.org/debian/libepoxy Thanks, Jeremy Bicha
Bug#909134: RFS: budgie-extras/0.6.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "budgie-extras" * Package name: budgie-extras Version : 0.6.1-1 Upstream Author : Ubuntu Budgie Developers * URL : https://github.com/ubuntubudgie/budgie-extras * License : GPL-3+ Section : misc It builds those binary packages: budgie-app-launcher-applet - Applet to provide an alternative means to launch applications budgie-clockworks-applet - Applet to display clock across multiple time zones budgie-countdown-applet - Applet providing a countdown capability on the Budgie Desktop budgie-dropby-applet - Applet to popup when a USB device is connected budgie-hotcorners-applet - Applet providing hotcorners capabilities for the Budgie Desktop budgie-kangaroo-applet - Applet to allow quick file-browsing budgie-keyboard-autoswitch-applet - Applet adding the ability to set a different keyboard layout per budgie-previews-applet - Applet providing window previews capabilities for the Budgie Desk budgie-quicknote-applet - Applet providing simple notes capability for the Budgie Desktop budgie-recentlyused-applet - Applet displays files recently accessed for the Budgie Desktop budgie-rotation-lock-applet - Applet to lock or unlock the screen rotation budgie-showtime-applet - Applet displaying date and time on the Budgie Desktop budgie-trash-applet - Applet allows access to trash capabilities for the Budgie Desktop budgie-weathershow-applet - Applet to display the weather and forecast budgie-window-mover-applet - Applet allows moving windows between workspaces for the Budgie De budgie-workspace-overview-applet - Applet providing quick access to workspaces for the Budgie Deskto budgie-workspace-wallpaper-applet - Applet providing per workspace wallpaper To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-extras Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.6.1-1.dsc Notes: linitan -i -I --pedantic run on the built source and is lintian free check-all-the-things run on the source and corrections made to the source pbuilder-dist run to ensure builds correctly for unstable This upload introduces new built binaries to be authorised by archive-admins via the NEW queue: - budgie-trash-applet - budgie-recentlyused-applet - budgie-app-launcher-applet - budgie-weathershow-applet - budgie-hotcorners-applet - budgie-quicknote-applet May I request that this package be added to my debian maintainers list of packages I'm allowed to look after (dak fossfree...@ubuntu.com) ? Changes since the last upload: (Most recent changelog) * New upstream release - see ChangeLog for details - Consolidated release to resync Debian and Ubuntu versions * Packaging Changes: - Bump Standards-Version - no changes required Regards, David Mohammed
Bug#890360: RFP: vlc-plugin-bittorrent -- Bittorrent plugin for VLC
Control: retitle -1 ITP: vlc-plugin-bittorrent -- Bittorrent plugin for VLC Control: owner -1 p...@debian.org I plan to upload this into Debian. -- Happy hacking Petter Reinholdtsen
Bug#909133: ITP: auto-dictionary-el -- automatic dictionary switcher for Emacs spell checking
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Package name: auto-dictionary-el Version : 1.1 Upstream Author : Nikolaj Schumacher URL : https://wiki.debian.org/EmacsenTeam/Team License : GPL-2+ Programming Lang: elisp Description : automatic dictionary switcher for Emacs spell checking Auto-dictionary is a minor mode that automatically sets 'ispell-dictionary'. It hooks into flyspell's on-the-fly spell checking, and extends these checks to also detect language. This package is useful for Emacs users who work in multiple languages. . Auto-dictionary supports the following languages: Catalan Classical Greek - ἑλληνικά Danish - Dansk English Esperanto French - Français German - Deutsch Hindi - हिन्दी Hungarian - Magyar Modern Greek - νέα ελληνικά Norwegian Bokmål Norwegian Nynorsk Portuguese - Português Romanian - Românâ, Româneşte Slovak - Slovenčina Slovene - Slovenian Spanish - Español Swedish - Svenska -- Antoine, does it detect language with per-buffer granularity, or support mixing languages in the same buffer? Thanks for mentioning that you use this software on #debian-emacs :-) P.S. please ping me if I take more than two weeks to package this I do not yet use this package and have been manually switching between languages, which is why I'm motivated to package it. I plan to maintain it as part of the Debian Emacsen Team, and the team policy is here: https://wiki.debian.org/EmacsenTeam/Team I will require a sponsor for the initial upload. Regards, Nicholas
Bug#804867: rubber: Always runs bibtex when bibliography is a symbolic link
found 804867 1.5.1-1 stop On 12.11.15 Dylan Thurston (d...@bostoncoop.net) wrote: > This is a followup on Bug #798991. rubber no longer crashes when the > bibliography is a symbolic link as described there, but it doesn't > work correctly either: it keeps rerunning bibtex, regardless of > whether the bibliography has changed or not. Here's a minimal example; > note how many times bibtex was run. > Still in 1.5.1-1. H. -- sigmentation fault
Bug#909040: davmail: A JNI error has occurred
Hi, > This is a jarwrapper bug, the CheckProperty class was compiled without > specifying the source/target level, thus defaulting to Java 10 bytecode > (version 54.0). Thanks but the second part of the stacktrace is still on davmail. I need to investigate between these options: 1) make the binary package use java10 but this will require an upload when java11 is out 2) wrapper script to force the user to use java10 3) make it possible to compile davmail with target=1.8 and thus without --add-exports I'd be happy to get advice on this. I think I'll try 3) first. Alex
Bug#909089: debhelper: GNU configure $prefix expanded too early?
On 2018-09-18 14:09 +0300, Peter Pentchev wrote:
> Package: debhelper
> Version: 11.4
> Severity: serious
>
> Hi,
>
> Thanks for maintaining and extending debhelper!
>
> I don't have much information right now, maybe I'll look into it in
> the evening (Eastern European time), but trying to build gforth in
> a chroot containing debhelper-11.4 results in a package where all
> the paths passed to the GNU configure script as "\$prefix/something"
> are actually defined as "/something", thus placing binaries in /bin,
> include files in /include, etc. Installing debhelper-11.3.5 fixes
> the problem.
Bisection shows that commit a7ec05c10093f ("dh: Track which options have
been passed") has triggered the problem. I had a look at the gforth
build logs with debhelper 11.3.5 and 11.4, but could not spot an obvious
cause. Maybe Niels has more luck.
Cheers,
Sven
Bug#907477: maven-debian-helper: does not substitute values of plugins with maven.rules
Am 06.09.18 um 12:52 schrieb Markus Koschany: > > > Am 06.09.2018 um 00:03 schrieb Emmanuel Bourg: >> Le 28/08/2018 à 15:25, Markus Koschany a écrit : >> For plugins and poms the exact type and version have to be specified in >> the substitution rule. For example: >> >> org.apache.xbean maven-xbean-plugin maven-plugin s/4.1/4.5/ * * >> >> I have no idea if this was designed that way or if it's a bug. I just fixed an identical bug in activemq #907688 but org.apache.xbean maven-xbean-plugin maven-plugin s/4.2/4.5/ * * didn't work. It already failed in the root pom.xml but is even more complicated because this package uses two different versions of maven-xbean-plugin, the other dependency is in the activemq-spring module. signature.asc Description: OpenPGP digital signature
Bug#909117: RFS: libmd5-rfc/0.0+20020413-1 [ITP]
On Wed, Sep 19, 2018 at 12:37:19AM +0800, Yangfl wrote: > * Package name: libmd5-rfc >Version : 0.0+20020413 >Upstream Author : Aladdin Enterprises > * URL : https://sourceforge.net/projects/libmd5-rfc/ > libmd5-rfc-dev - RFC1321-based (RSA-free) MD5 library - development headers > libmd5-rfc0 - RFC1321-based (RSA-free) MD5 library > * Initial release (Closes: #909116) The package technically looks good (one nitpick: rm debian/clean, but this is too minor to really bother). I'm ready to upload at any time. But, with md5 thoroughly broken, do you have any reason to include this library? It's unfit for cryptographic purposes, and there exist much faster hashes for non-crypto uses. Thus, I'd recommend introducing this package only if you have some actual use -- such as another package wanting to depend on it. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17] ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37] ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Bug#896698: deprecating needs-recommends
On Tue, Sep 18, 2018 at 08:53:05PM +0200, Paul Gevers wrote: > Hi, > > On 18-09-18 17:21, gregor herrmann wrote: > > On Mon, 17 Sep 2018 15:11:30 -0700, Antonio Terceiro wrote: > > > >>> So if needs-recommends vanishes, there will be at least dozens if not > >>> hundreds of perl packages which will immediately fail their > >>> autopkgtests. > >> > >> Yes. We will need to find a replacement before dropping needs-recommends > >> completely.> > > Thanks. > > I think autodep8 (which is doing the work for these perl packages) must > be fixed before we can remove needs-recommends. It should already add > the recommends to the test dependencies. (but see my comments below). > > >> Maybe we want autopkgtest to also support @recommends@ alongside > >> @builddeps@? > > > > From a user's point of view, that sounds ok to me. > > Updating a few bits of documentation and a handful of packages with > > manual d/t/control shouldn't be a problem. > > On the one hand, I wonder what that is going to help. This is just > changing semantics as it still means that autopkgtest needs to figure it > out. The current situation is going to waste peoples time debugging why > a test is a regression, just to find out that every tool is silent on > not installing the recommends. On the other hand, it is a clearer > statement and it means that we can explain and document what we really > mean with it. > > @recommends@ or needs-recommends should mean that direct recommends of > the binary packages from the package that provides the autopkgtest are > test dependencies. Implementation wise, this would mean that we would > add all recommends, whether the binary that recommends it is installed > or not. > > If the feature to have recommends in the test dependencies isn't going > away, how bad would it be if we change the behavior in a sustainable > way? In my endeavors to fix this bug, I have missed the option to just > add the sum of all the Recommends lines to the test dependencies, like > we do with @builddeps@. What do people think? That would work as well, with the benefit that it would require changing only autopkgtest and nothing else. And I think that adding the packages in Recommends to test dependencies is compatible with the original spirit of needs-recommends, which is "this test needs the recommended packages installed", but does it in a way that actually works. signature.asc Description: PGP signature
Bug#909132: RM: npapi-vlc/2.0.6-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove npapi-vlc from stretch. With firefox-esr dropping support for NPAPI plugins, the plugin is no longer usable. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#909122: diffoscope: MemoryError when comparing big ISO images
Marek Marczykowski-Górecki wrote on Tue, 18 Sep 2018 21:09 +0200: > On Tue, Sep 18, 2018 at 09:00:11PM +0200, Marek Marczykowski-Górecki wrote: > > On Tue, Sep 18, 2018 at 06:39:28PM +, Daniel Shahaf wrote: > > > Slurping the file to a string object is an antipattern. Instead of > > > using f.read() to create a 4.5GB string, it would be better to use > > > json.load(f) to read the file incrementally. That should raise an > > > exception rather quickly. > > > > That may be even better! Expect MR in a moment. Should I include some > > magic text in commit message to link it with this bug? > > Nope, json.load: > > def load(fp, *, cls=None, object_hook=None, parse_float=None, > ... > return loads(fp.read(), > ... I stand corrected... ... and surprised. Cheers, Daniel
Bug#879905: glee: source for GLee.c and GLee.h is missing
On Mon, 6 Nov 2017 02:08:44 +0100 Steve Cotton wrote: > On Fri, Oct 27, 2017 at 07:55:52AM +0200, Steve Cotton wrote: > > On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote: > > > These files are clearly not source code. But luckily it should > > > be possible to regenerate them from the git repo I mentioned: > > > > > > > [..] https://github.com/kallisti5/glee > > > > It seems that repo is also not the complete source, the build > > steps in CMakeLists.txt download specs for the GL extensions from > > http://www.opengl.org/registry/ > > It doesn't manage to download the specifications any more, which is > probably because the website has changed since 2011. OTOH, anything > that works with Debian's 2009 version of GLee can only be using > extensions that existed in 2009. > > AFAICS, what GLeeGen creates is a mix of: > > 1. An easy wrapper for checking if an extension is supported > 2. The DFSG-free files which are now packaged in khronos-api > 3. The specifications under Khronos' speccopyright (not DFSG-free) > > The speccopyright means that we can't make a DFSG version of GLee, but > it also seems that it might be easier to just fix the rdeps to not use > GLee at all. The wrapper for checking if extensions are supported > could be ported to use the khronos-api, if it's needed at all. > > Looking at the packages that use GLee: > > Fife: only a few extensions, all of them now in khronos-api. Would > need the wrapper function. > > FS-UAE: build-depends on glee-dev, but the changelog includes "use > GLEW instead of GLee", none of the binaries depend on libglee, and the > two #includes in the source are commented out. Bug #880944 logged. > > Out Of Order: transitive dependency via Sludge > > Pink Pony: build-depends on glee-dev, but doesn't #include GLee.h > anywhere. Builds and runs fine without it (bug #880941 logged for > dropping the dependency). > > Sludge: if a compile-time check finds OpenGL ES 2.0, the code assumes > that all of the extensions that it wants are already present, and > doesn't use GLee's wrapper. > > Unknown Horizons: transitive dependency via Fife > > Steve > > I ported sludge to use glew instead of glee, and it was the last rdep. glee can be removed now. Best, Tobias
Bug#909122: diffoscope: MemoryError when comparing big ISO images
Hi Marek, > magic text in commit message to link it with this bug? Sure: "Blah blah blah. (Closes: #909122)" Thanks! Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#909122: diffoscope: MemoryError when comparing big ISO images
On Tue, Sep 18, 2018 at 09:00:11PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Sep 18, 2018 at 06:39:28PM +, Daniel Shahaf wrote: > > Slurping the file to a string object is an antipattern. Instead of > > using f.read() to create a 4.5GB string, it would be better to use > > json.load(f) to read the file incrementally. That should raise an > > exception rather quickly. > > That may be even better! Expect MR in a moment. Should I include some > magic text in commit message to link it with this bug? Nope, json.load: def load(fp, *, cls=None, object_hook=None, parse_float=None, ... return loads(fp.read(), ... -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature
Bug#901249: xterm: translation overrides for copy/paste do not work as documented
Thomas Dickey dixit: >actually it was never intended that you could select both at the same >time. In #336, I've disallowed that. What does that even mean, wrt. the bug report? bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Bug#909122: diffoscope: MemoryError when comparing big ISO images
On Tue, Sep 18, 2018 at 06:39:28PM +, Daniel Shahaf wrote: > Slurping the file to a string object is an antipattern. Instead of > using f.read() to create a 4.5GB string, it would be better to use > json.load(f) to read the file incrementally. That should raise an > exception rather quickly. That may be even better! Expect MR in a moment. Should I include some magic text in commit message to link it with this bug? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature
Bug#908698: smarty3: CVE-2018-16831
On Tue, Sep 18, 2018 at 05:06:14PM +, Mike Gabriel wrote: > > But let's wait for a few more days to spot eventual regressions reported > > in unstable first. Also, make sure to coordinate the release of the DLA with > > the DSA, otherwise we end up with a situation where oldstable has a higher > > version number than stable. > > I will wait another week with this. I'd like to get this solved before my > VAC (6th Oct - 21st Oct). Sounds good. Cheers, Moritz
Bug#725408: org-mode 8 info does not show up in info index
On Thu, Sep 13, 2018 at 12:35:55AM -0400, Nicholas D Steeves wrote: > > But I found a possible solution that could be used for other packages > that provide updated submodules of a big package! > ## > INFOPATH="/usr/share/doc/org-mode-doc:" > export INFOPATH > ## > > From > https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Other-Info-Directories.html > Also from that page is this: As one final alternative, which works only with Emacs Info, you can change the Info-directory-list variable. For example: (add-hook 'Info-mode-hook '(lambda () (add-to-list 'Info-directory-list (expand-file-name "~/info" dh-elpa's TODO has: * missing features *** info - completely untested at the moment For the sake of completeness it's worth mentioning that the dh-elpa could hypothetically add new paths to Info-directory-list; however, given that this bug is about how the updated info page isn't found by the standalone Info reader, modifying the environmental variable INFOPATH seems like the necessary approach. Instead of doing this with per-package granularity, maybe '--with elpa' could tell dh_installinfo to install to /usr/share/info/elpa/foo.info instead of /usr/share/foo.info? -- Nicholas signature.asc Description: PGP signature
Bug#909130: firefox-esr: upgrade to 60.2.0-esr requires downgrading libavcodec-extra to libavcodec
Package: firefox-esr Version: 60.2.0esr-1 Severity: normal Dear Maintainer, trying to upgrade firefox-esr to 60.2.0-esr causes already installed libavcodec-extra being uninstalled and replaced for plain libavcodec packages. *-extra packages can be installed back after the upgrade without dependency problems, so it's an annoyance only. Versions of packages firefox-esr depends on: ii debianutils 4.8.6 ii fontconfig2.13.0-5 ii libatk1.0-0 2.28.1-1 ii libc6 2.27-6 ii libcairo-gobject2 1.15.12-1 ii libcairo2 1.15.12-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-2 0.110-3 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-8 ii libfontconfig12.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-6 ii libgdk-pixbuf2.0-02.36.12-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-03.22.30-2 ii libhunspell-1.6-0 1.6.2-1+b1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.39-1 ii libpango-1.0-01.42.4-1 ii libsqlite3-0 3.24.0-1 ii libstartup-notification0 0.12-5 ii libstdc++68.2.0-6 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.6-1 ii libx11-xcb1 2:1.6.6-1 ii libxcb-shm0 1.13-3 ii libxcb1 1.13-3 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox-esr recommends: pn libavcodec58 | libavcodec57 | libavcodec56 | libavcodec55 | libavco Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-5 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-6 ii libgssapi-krb5-2 1.16-2 ii libgtk2.0-02.24.32-3 -- no debconf information
Bug#909131: stretch-pu: package kmodpy/0.1.10-2.1~deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
apt-get install python-kmodpy:i386 python-kmodpy:amd64
This resulted in a situtation where the user could neither
install and nor remove the packages without editing the prerm.
diff -Nru kmodpy-0.1.10/debian/changelog kmodpy-0.1.10/debian/changelog
--- kmodpy-0.1.10/debian/changelog 2015-07-03 11:57:57.0 +0300
+++ kmodpy-0.1.10/debian/changelog 2018-09-18 21:50:25.0 +0300
@@ -1,3 +1,17 @@
+kmodpy (0.1.10-2.1~deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for stretch.
+
+ -- Adrian Bunk Tue, 18 Sep 2018 21:50:25 +0300
+
+kmodpy (0.1.10-2.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Remove the incorrect Multi-Arch: same. (Closes: #897223)
+
+ -- Adrian Bunk Sun, 16 Sep 2018 13:26:10 +0300
+
kmodpy (0.1.10-2) unstable; urgency=medium
* Bump S-V to 3.9.6.
diff -Nru kmodpy-0.1.10/debian/control kmodpy-0.1.10/debian/control
--- kmodpy-0.1.10/debian/control2015-07-06 13:39:14.0 +0300
+++ kmodpy-0.1.10/debian/control2018-09-16 13:26:03.0 +0300
@@ -11,7 +11,6 @@
Package: python-kmodpy
Architecture: linux-any
-Multi-Arch: same
Depends: ${misc:Depends}, ${python:Depends}, libkmod2 (>=18-1)
Description: Python binding for kmod
The libkmod2 is a library that provides an API for insertion, removal,
Bug#908046: add option to hide pseudo filesystems
* Andreas Schwarz [180918 13:00]: > This possibility already exists. > > The -s switch is basically for skipping certain devices, but since > pseudo file systems use their identifiers as devices, you can also use > this. > > See lsmount.rc.example > > skip = > "sysfs,proc,udev,sunrpc,devpts,tmpfs,cgroup,pstore,systemd-1,mqueue,securityfs,debugfs,configfs,hugetlbfs,fusectl"; Okay, thanks. I was hoping for something where I didn't have to enumerate all possible pseudo file systems, but I guess somebody has to maintain that list. It would be nice if the list were in a single place, rather than each user having to maintain the same list on all systems where lsmount was installed. BTW, I would not include tmpfs in that list; those file systems are modifiable by normal users. Also, replace securityfs with none, as that is the device name used by that file system type. If you are not willing to maintain the list inside lsmount (perhaps as an alias device name 'pseudo' recognized by skip), then you can go ahead and close this bug. Thanks...Marvin
Bug#882287: xul-ext-noscript: new upstream version
Jerome BENOIT wrote... > Please consider to the new upstream version 10 > given that the current version of noscript provided in Stretch > does not work with firefox-esr 60.2 recently brought in Stretch. +1 In an attempt to have a usable noscript again, I tried to build the new version but this failed: | make[1]: Entering directory '/<>' | uglifyjs -o \ | chrome/content/noscript/antlr.js \ | debian/antlr3-all.js | fs.js:646 | return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode); | ^ | | Error: ENOENT: no such file or directory, open 'chrome/content/noscript/antlr.js' | at Object.fs.openSync (fs.js:646:18) | at Object.fs.writeFileSync (fs.js:1299:33) | at done (/usr/lib/nodejs/uglify-js/bin/uglifyjs:527:16) | at cb (/usr/lib/nodejs/uglify-js/bin/uglifyjs:324:39) | at /usr/lib/nodejs/uglify-js/bin/uglifyjs:391:9 | at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:511:3) This needs somebody with a deeper understanding of the webext concept the the build system. Christoph signature.asc Description: PGP signature
Bug#896698: deprecating needs-recommends
Hi, On 18-09-18 17:21, gregor herrmann wrote: > On Mon, 17 Sep 2018 15:11:30 -0700, Antonio Terceiro wrote: > >>> So if needs-recommends vanishes, there will be at least dozens if not >>> hundreds of perl packages which will immediately fail their >>> autopkgtests. >> >> Yes. We will need to find a replacement before dropping needs-recommends >> completely.> > Thanks. I think autodep8 (which is doing the work for these perl packages) must be fixed before we can remove needs-recommends. It should already add the recommends to the test dependencies. (but see my comments below). >> Maybe we want autopkgtest to also support @recommends@ alongside >> @builddeps@? > > From a user's point of view, that sounds ok to me. > Updating a few bits of documentation and a handful of packages with > manual d/t/control shouldn't be a problem. On the one hand, I wonder what that is going to help. This is just changing semantics as it still means that autopkgtest needs to figure it out. The current situation is going to waste peoples time debugging why a test is a regression, just to find out that every tool is silent on not installing the recommends. On the other hand, it is a clearer statement and it means that we can explain and document what we really mean with it. @recommends@ or needs-recommends should mean that direct recommends of the binary packages from the package that provides the autopkgtest are test dependencies. Implementation wise, this would mean that we would add all recommends, whether the binary that recommends it is installed or not. If the feature to have recommends in the test dependencies isn't going away, how bad would it be if we change the behavior in a sustainable way? In my endeavors to fix this bug, I have missed the option to just add the sum of all the Recommends lines to the test dependencies, like we do with @builddeps@. What do people think? Paul signature.asc Description: OpenPGP digital signature
Bug#909129: gkermit FTCBFS: does not pass cross tools to make
Source: gkermit Version: 1.0-10 Tags: patch User: helm...@debian.org Usertags: rebootstrap gkermit fails to cross build from source, because it does not pass cross tools to make. The simplest way to fix that is using dh_auto_build. When doing so, it fails to cross build with an Exec format error while running ./gwart. It turns out that gwart is a build tool and needs to be built for the build architecture. The attached patch takes care of that and makes gkermit cross buildable. Please consider applying it. Helmut diff -u gkermit-1.0/debian/changelog gkermit-1.0/debian/changelog --- gkermit-1.0/debian/changelog +++ gkermit-1.0/debian/changelog @@ -1,3 +1,12 @@ +gkermit (1.0-10.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. ++ Build the gwart tool for the build architecture. + + -- Helmut Grohne Tue, 18 Sep 2018 20:41:14 +0200 + gkermit (1.0-10) unstable; urgency=medium * QA upload diff -u gkermit-1.0/debian/rules gkermit-1.0/debian/rules --- gkermit-1.0/debian/rules +++ gkermit-1.0/debian/rules @@ -6,15 +6,14 @@ #export DH_VERBOSE=1 # Include dpatch stuff. +include /usr/share/dpkg/architecture.mk include /usr/share/dpatch/dpatch.make build: patch build-stamp build-stamp: dh_testdir - - # Add here commands to compile the package. - $(MAKE) - + dpkg-architecture -f -a$(DEB_BUILD_ARCH) -c dh_auto_build -- gwart + dh_auto_build touch build-stamp clean: unpatch
Bug#909128: gcc-defaults: debian/rules control duplicates amd64 compilers when regenerated on arm64 hosts
Source: gcc-defaults Version: 1.179 Severity: normal Dear Maintainer, If you run debian/rules control on an arm64 machine dpkg barfs warning about duplicate *-x86-64-linux-gnu packages causing the build to fail. This is probably due to clashing special casing for the amd64 packages. A simple patch to fix this is: --- gcc-defaults-1.179/debian/rules 2018-08-16 10:44:12.0 + +++ gcc-defaults-1.179-ajb/debian/rules 2018-09-18 18:30:03.621593507 + @@ -366,7 +366,7 @@ $(if $(filter $(DEB_HOST_ARCH), i386 x32), amd64) \ $(if $(filter $(DEB_HOST_ARCH), amd64 x32), i386) else ifeq ($(DEB_HOST_ARCH),arm64) - CROSS_ARCHS = amd64 armel armhf i386 + CROSS_ARCHS = armel armhf i386 else ifeq ($(DEB_HOST_ARCH),ppc64) CROSS_ARCHS = ppc64el else ifeq ($(DEB_HOST_ARCH),ppc64el) This is a problem as amd64 is always added to the build in: ifeq ($(with_cross),yes) : # FIXME: filter-out some gdc and gccgo multilib configs $(foreach a,amd64 $(CROSS_ARCHS), \ I think either amd64 shouldn't be in the cross arch filters or shouldn't be unconditionally added later on. This may apply to other architectures too and would probably show up if the control files where regularly regenerated on non-x86 hosts. Regards, Alex.
Bug#909118: /proc not mounted before use
George Taylor writes ("Re: Bug#909118: /proc not mounted before use"):
> On 18/09/2018, Ian Jackson wrote:
> > Thanks. Have you tried this on a system _with_ a Debian-generated
> > initramfs ?
>
> Yes, on a Debian 9 VM. When using initramfs /proc/stat exists at that
> point and so the uname test never happens.
Great, thanks.
(I hope you don't mind that I'm CCing this to the bug so there's a
record of your reply.)
Ian.
Bug#909127: stretch-pu: package ibus/1.5.14-3+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
apt-get install gir1.2-ibus-1.0:i386 gir1.2-ibus-1.0:amd64
This resulted in a situtation where the user could neither
install and nor remove the packages without editing the prerm.
diff -Nru ibus-1.5.14/debian/changelog ibus-1.5.14/debian/changelog
--- ibus-1.5.14/debian/changelog2017-05-20 14:36:04.0 +0300
+++ ibus-1.5.14/debian/changelog2018-09-18 21:14:51.0 +0300
@@ -1,3 +1,11 @@
+ibus (1.5.14-3+deb9u1) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove the dependency of the gir package against python,
+it breaks multiarch installation. (Closes: #889053)
+
+ -- Adrian Bunk Tue, 18 Sep 2018 21:14:51 +0300
+
ibus (1.5.14-3) unstable; urgency=medium
* Set ENABLE_APPINDICATOR_ENGINE_ICON by installing qtbase5-dev.
diff -Nru ibus-1.5.14/debian/control ibus-1.5.14/debian/control
--- ibus-1.5.14/debian/control 2017-05-20 09:18:43.0 +0300
+++ ibus-1.5.14/debian/control 2018-09-18 21:14:51.0 +0300
@@ -143,7 +143,7 @@
Section: introspection
Architecture: any
Multi-Arch: same
-Depends: ${gir:Depends}, ${misc:Depends}, ${python3:Depends}
+Depends: ${gir:Depends}, ${misc:Depends}
Description: Intelligent Input Bus - introspection data
IBus is an Intelligent Input Bus. It is a new input framework for the Linux
OS. It provides full featured and user friendly input method user interface.
Bug#909122: diffoscope: MemoryError when comparing big ISO images
Marek Marczykowski-Górecki wrote on Tue, Sep 18, 2018 at 20:17:03 +0200:
> File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py",
> line 52, in recognizes
> f.read().decode('utf-8', errors='ignore'),
> MemoryError
>
> The JSONFile.recognizes function, for context:
>
> @classmethod
> def recognizes(cls, file):
> with open(file.path, 'rb') as f:
> # Try fuzzy matching for JSON files
> is_text = any(
> file.magic_file_type.startswith(x)
> for x in ('ASCII text', 'UTF-8 Unicode text'),
> )
> if is_text and not file.name.endswith('.json'):
> buf = f.read(10)
> if not any(x in buf for x in b'{['):
> return False
> f.seek(0)
>
> try:
> file.parsed = json.loads(
> f.read().decode('utf-8', errors='ignore'),
> object_pairs_hook=collections.OrderedDict,
> )
Slurping the file to a string object is an antipattern. Instead of
using f.read() to create a 4.5GB string, it would be better to use
json.load(f) to read the file incrementally. That should raise an
exception rather quickly.
> except ValueError:
> return False
>
> return True
> Obviously ISO file is not JSON.
> The whole thing could be avoided if earlier check (if initial 10 chars
> contains '[' or '{') would be executed not only on "text" files.
> Any reasons for that "is_text" there? Alternatively, if is_text=False,
> maybe the function should return False early?
>
> I can provide a patch for either option, but I'd like to know which one
> of them you prefer.
No opinion on these.
Thanks for including the function in the report.
Cheers,
Daniel
Bug#909125: ffcall FTCBFS: wrong use of AC_TRY_RUN
Source: ffcall Version: 2.1-2 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap ffcall fails to cross build from source, because there are three cases where AC_TRY_RUN is used wrongly. The arguments for AC_TRY_RUN are: 1. program source 2. success code 3. failure code 4. cross compile code In three cases, the third argument was skipped. That is evident from the comments in the actual third argument hinting that the argument was intended for cross compilation but actually got used for the failure case. Inserting the missing failure case makes ffcall cross buildable. Please consider applying the attached patch. Helmut --- ffcall-2.1.orig/m4/codeexec.m4 +++ ffcall-2.1/m4/codeexec.m4 @@ -177,6 +177,7 @@ } ], [ffcall_cv_malloc_mprotect_can_exec=yes], + [ffcall_cv_malloc_mprotect_can_exec=no], [dnl When cross-compiling, assume SELinux on Linux. dnl If we don't know, assume the worst. case "$host_os" in @@ -267,6 +268,7 @@ } ], [ffcall_cv_mmap_mprotect_can_exec=yes], + [ffcall_cv_mmap_mprotect_can_exec=no], [dnl When cross-compiling, assume SELinux on Linux. dnl If we don't know, assume the worst. case "$host_os" in @@ -339,6 +341,7 @@ } ], [ffcall_cv_mmap_shared_can_exec=yes], + [ffcall_cv_mmap_shared_can_exec=no], [dnl When cross-compiling, assume yes, since this is the result dnl on all the platforms where we have tested it. ffcall_cv_mmap_shared_can_exec="guessing yes"
Bug#909126: ompl-plannerarena: missing Breaks+Replaces: ompl-demos (<< 1.4)
Package: ompl-plannerarena Version: 1.4.0+ds1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../ompl-plannerarena_1.4.0+ds1-1_all.deb ... Unpacking ompl-plannerarena (1.4.0+ds1-1) ... dpkg: error processing archive /var/cache/apt/archives/ompl-plannerarena_1.4.0+ds1-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/plannerarena.1.gz', which is also in package ompl-demos 1.2.1+ds1-1 Errors were encountered while processing: /var/cache/apt/archives/ompl-plannerarena_1.4.0+ds1-1_all.deb cheers, Andreas ompl-demos=1.2.1+ds1-1_ompl-plannerarena=1.4.0+ds1-1.log.gz Description: application/gzip
Bug#909122: diffoscope: MemoryError when comparing big ISO images
Hi Marek,
> The whole thing could be avoided if earlier check (if initial 10 chars
> contains '[' or '{') would be executed not only on "text" files.
Indeed. The origins of this appear to be:
https://salsa.debian.org/reproducible-builds/diffoscope/commit/2a758d3d0205e934ed6dffebb5d6462b00fe590d
> I can provide a patch for either option, but I'd like to know which one
> of them you prefer.
I'm not quite sure but I would probably go with dropping the whole
`is_text` thing but keeping everything the same. Are you happy and
comfortable creating an MR for this? Thanks in advance…
> Obviously ISO file is not JSON.
♥
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#909124: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed
Package: quilt Version: 0.65-2 Severity: wishlist Dear Maintainer, In a minimal sid chroot, where less(1) is not installed: % QUILT_PATCHES=debian/patches quilt series /usr/share/quilt/scripts/patchfns: line 1109: less: command not found % Please consider using a fallback (such as /usr/bin/pager or no pager at all) when less(1) is not installed. Cheers, Daniel P.S. Filing this as a wishlist bug because I see that quilt Recommends: less.)
Bug#909123: ruby-active-model-serializers: /usr/bin/rubocop is already shipped by the rubocop package
Package: ruby-active-model-serializers Version: 0.10.7-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files. Adding Breaks+Replaces is probably not the correct solution in this case. >From the attached log (scroll to the bottom...): Preparing to unpack .../ruby-active-model-serializers_0.10.7-1_all.deb ... Unpacking ruby-active-model-serializers (0.10.7-1) ... dpkg: error processing archive /var/cache/apt/archives/ruby-active-model-serializers_0.10.7-1_all.deb (--unpack): trying to overwrite '/usr/bin/rubocop', which is also in package rubocop 0.52.1+dfsg-1 Errors were encountered while processing: /var/cache/apt/archives/ruby-active-model-serializers_0.10.7-1_all.deb cheers, Andreas rubocop=0.52.1+dfsg-1_ruby-active-model-serializers=0.10.7-1.log.gz Description: application/gzip
Bug#909107: emacsen-common is trying to force me to upgrade from emacs23 to emacs25
On Tue, Sep 18, 2018, at 18:07, Edward Welbourne wrote: > Thus the recent update to emacsen-common's dependencies forces > uninstallation of emacs23, or never update anything again - aptitude > has a conflict to resolve, that it can't resolve without removing the> last > usable version of my editor. Are you volunteering to take on maintainership of emacs23 in Debian? If you are fanatical enough to take on that responsibility, that's odd but terrific; otherwise, I'm afraid there is no simple way to avoid upgrading to a version which is supported by the upstream Emacs maintainers. Expecting the Debian packagers to keep an old version alive without upstream support seems misdirected and wasteful. -- If this were a real .signature, it would suck less. Well, maybe not.
Bug#909114: [Pkg-zsh-devel] Bug#909114: Bug#909114: Bug#909114: Check for missing pcre module
Daniel Shahaf wrote on Tue, Sep 18, 2018 at 17:34:28 +: > Therefore the revised plan is: > > A. Teach upstream configure to fail hard if --with-pcre was passed and >pcre wasn't found. PCRE would remain optional if neither --with-pcre >nor --without-pcre was passed. > > B. Pass --with-pcre to configure in d/rules. > For clarity, there's already a --enable-pcre flag, and d/rules does pass it, but configure does not fail hard when --enable-pcre is passed and libpcre wasn't found. Such "fail hard" functionality should be added to configure and d/rules should use it. > C. Teach upstream test V07 to make the skip conditional, not on whether >pcre loads successfully, but on whether it was found by configure. >(This probably means looking in config.modules or in pcre.mdd or >something?) This will catch bugs where pcre was built but fails to load. I came up with this, but when I applied it to 5.6.2-2 the build didn't fail as I expected it to. Does anyone see the problem? [[[ diff --git a/Test/V07pcre.ztst b/Test/V07pcre.ztst index 9feeb47fb..ab67f3d80 100644 --- a/Test/V07pcre.ztst +++ b/Test/V07pcre.ztst @@ -1,11 +1,10 @@ %prep - if ! zmodload -F zsh/pcre C:pcre-match 2>/dev/null + if grep '^name=zsh/pcre .* link=no ' $ZTST_testdir/../config.modules >/dev/null then -ZTST_unimplemented="the zsh/pcre module is not available" +ZTST_unimplemented="the zsh/pcre module was disabled by configure (see config.modules)" return 0 fi -# Load the rest of the builtins zmodload zsh/pcre setopt rematch_pcre # Find a UTF-8 locale. ]]] Cheers, Daniel
Bug#909122: diffoscope: MemoryError when comparing big ISO images
Package: diffoscope
Version: 101
Severity: normal
Dear Maintainer,
When comparing two 4.5GB ISO images, diffoscope tries to load them into
memory, which fails with MemoryError in json comparator:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 470, in
main
sys.exit(run_diffoscope(parsed_args))
File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 442, in
run_diffoscope
difference = compare_root_paths(path1, path2)
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line
65, in compare_root_paths
file1 = specialize(FilesystemFile(path1, container=container1))
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/specialize.py",
line 49, in specialize
if try_recognize(file, cls, cls.recognizes):
File
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/specialize.py",
line 36, in try_recognize
if not recognizes(file):
File "/usr/lib/python3/dist-packages/diffoscope/comparators/json.py",
line 52, in recognizes
f.read().decode('utf-8', errors='ignore'),
MemoryError
Obviously ISO file is not JSON.
The whole thing could be avoided if earlier check (if initial 10 chars
contains '[' or '{') would be executed not only on "text" files.
Any reasons for that "is_text" there? Alternatively, if is_text=False,
maybe the function should return False early?
I can provide a patch for either option, but I'd like to know which one
of them you prefer.
The JSONFile.recognizes function, for context:
@classmethod
def recognizes(cls, file):
with open(file.path, 'rb') as f:
# Try fuzzy matching for JSON files
is_text = any(
file.magic_file_type.startswith(x)
for x in ('ASCII text', 'UTF-8 Unicode text'),
)
if is_text and not file.name.endswith('.json'):
buf = f.read(10)
if not any(x in buf for x in b'{['):
return False
f.seek(0)
try:
file.parsed = json.loads(
f.read().decode('utf-8', errors='ignore'),
object_pairs_hook=collections.OrderedDict,
)
except ValueError:
return False
return True
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.14.67-1.pvops.qubes.x86_64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages diffoscope depends on:
ii libpython3.6-stdlib3.6.6-1
ii python33.6.5-3
ii python3-distro 1.3.0-1
ii python3-distutils 3.6.6-1
ii python3-libarchive-c 2.1-3.1
ii python3-magic 2:0.4.15-2
ii python3-pkg-resources 40.2.0-1
Versions of packages diffoscope recommends:
ii abootimg 0.6-1+b2
ii acl 2.2.52-3+b1
pn apktool
ii binutils-multiarch 2.31.1-5
ii bzip21.0.6-9
ii caca-utils 0.99.beta19-2+b3
ii colord 1.3.3-2
ii db-util 5.3.1
ii default-jdk-headless 2:1.10-68
ii device-tree-compiler 1.4.7-3
ii docx2txt 1.4-1
ii e2fsprogs1.44.4-2
ii enjarify 1:1.0.3-4
ii fontforge-extras 0.3-4
ii fp-utils 3.0.4+dfsg-20
ii fp-utils-3.0.4 [fp-utils]3.0.4+dfsg-20
ii genisoimage 9:1.1.11-3+b2
ii gettext 0.19.8.1-7
ii ghc 8.2.2-4
ii ghostscript 9.25~dfsg-2
ii giflib-tools 5.1.4-3
ii gnumeric 1.12.41-1
ii gnupg2.2.10-1
ii imagemagick 8:6.9.10.8+dfsg-1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1
ii jsbeautifier 1.6.4-7
ii libarchive-tools 3.2.2-5
ii llvm 1:6.0-43
ii lz4 1.8.2-1
ii mono-utils 4.6.2.7+dfsg-1
ii odt2txt 0.5-1+b2
pn oggvideotools
ii openssh-client 1:7.8p1-1
ii pgpdump 0.33-1
ii poppler-utils0.63.0-2
ii procyon-decompiler 0.5.32-4
ii python3-argcomplete 1.8.1-1
ii python3-binwalk 2.1.2~git20180830+dfsg1-1
ii python3-debian 0.1.33
ii python3-defusedxml 0.5.0-1
ii python3-guestfs
Bug#909105: consider switching asciidoctor to Architecture: all
On Tue, Sep 18, 2018 at 09:47:34AM -0700, Joseph Herlant wrote: > I think you can find the explanations to those questions in #893467 > which is the origin of th split of the asciidoc package. I reported that bug. After reading my report three times, I see how you might have interpreted it that way. I wrote that there is a problem, "because asciidoctor is Architecture: all and implicitly Multi-Arch: no". The problem results from the combination of those fields, not from either single field. The satisfiability problem is fully solved by the Multi-Arch: foreign field alone regardless of the Architecture value. Helmut
