Bug#974616: nomacs: "charset=Ascii" appears before the comment of the image
Control: tags -1 + upstream This *is* an upstream bug, as the upstream README.md has build instructions for Ubuntu that list libexiv2-dev (no version constraint given) as a required package. As far as I can tell, it's unaddressed as of the current tip of the master branch. I don't see that anyone has reported it as an issue on GitHub either. (I don't want a GitHub account, so I won't report it myself.) My only interest in this bug is that it has kept nomacs out of bullseye; I don't need its EXIF support. If this package isn't effectively orphaned, perhaps the maintainer can lower the bug's severity? (And/or forward the report upstream...)
Bug#932749: Debian packaging of EclipseLink is missing essential classes
Package: libeclipselink-java Version: 2.6.6-1 Severity: grave When running a very simple test application, or indeed any production application I have at hand, using the Debian-packaged version of EclipseLink, I run into the following error when calling javax.persistence.Persistence.createEntityManagerFactory: [...] Caused by: java.lang.ClassNotFoundException: org.eclipse.persistence.internal.libraries.asm.ClassVisitor at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 9 more Indeed eclipselink-2.6.6/debian/excludesfiles/build contains the following line: org/eclipse/persistence/internal/libraries/** I conclude that the Debian packaging of EclipseLink is unusable at the moment, hence the severity setting. (The same applications work fine with upstream's eclipselink.jar. I'm not sure why this library is packaged in Debian, as nothing in buster seems to depend on it.)
Bug#895381: Severity
* micah anderson [2019-01-20 21:03:53 +0100]: > I'm not disputing this bug exists, I'm just trying to determine why it > is you set the severity to "Serious". As you are probably aware, this > severity indicates that this is a sever violation of Debian policy > (violates a "must" or "required" directive), or in the package > maintainer's opinion, makes the package unsuitable for release. Oh. In the package maintainer's opinion. I had missed that part; my apologies. No, I don't claim a policy violation on this one and of course I'll defer to the package maintainer's assessment. I do find the bug scary, though, due to the possibility of silent corruption, and have been running a privately patched version of the package for that reason.
Bug#895404: NFS server stops accepting mount request / mounted NFS directories became inaccessible on client
control: severity -1 normal control: tags -1 + moreinfo Dear reporter, I'm sorry to hear that you have lost data. However, it doesn't seem very constructive to make a bug release-critical without providing enough detail to make a fix possible. NFS is a complex network protocol, and the root cause of unexpected behaviour isn't always obvious at first glance. First of all, has this bug been filed against the right package? The nfsd processes are actually kernel threads (that's one reason "kill -9" doesn't work on them), the corresponding package is the kernel image. How many clients are accessing that NFS server when the problem occurs? I see that you have RPCNFSDCOUNT=8 but the address range for allowed clients is a /27. If you have 30 clients all trying to write at the same time, some of them are going to have to wait until a server thread becomes available. "server not responding, still trying" is a common symptom of this. Have you tried tuning the server? You can adjust the thread count without a reboot. I don't see sec=krb5p in your /etc/exports, so NFS traffic on the wire is probably unencrypted. Have you looked at it with tcpdump or a similar tool, particularly when the problem occurs? For example it would be nice to know whether that "Connection timed out" you get from mount.nfs is for the portmapper (unlikely), for mountd, or for nfsd itself. (strace may also tell you some of this.) Are you familiar with rpcdebug? If client traffic is coming in but the server isn't replying, you could set debugging flags and look at kernel log output. Other available debugging tools include the kernel's event tracing subsystem, as well as nfsstat, nfsiostat and mountstats from package nfs-common. (The last two are client-side, so maybe not so useful if your problem really is at the server end.) I can't help you much more than this: my own environment is NFSv4-only (and I feel no urge to look back) while yours is anything but. But if you manage to pinpoint more precisely what's wrong, someone else may be able to provide better hints (or you may figure it out yourself).
Bug#895381: rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5'
Package: nfs-common Version: 1:1.3.4-2.1 Severity: serious Tags: fixed-upstream patch One of my systems has logged rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5' This turns out to be a known problem, covered extensively in https://bugzilla.redhat.com/show_bug.cgi?id=1419280 Please cherry-pick upstream commit 5ae8be8b6af1a0fdf2fa26051a05d4c04d028849 (and possibly 0a4f5e4daccdeba767b9ef36e30efbd7fd9a76d8 as well, although I'd rate that at a lower severity).
Bug#891325: Info received (Bug#891325: Acknowledgement (xfce4-weather-plugin: search function violates provider's usage policy))
Here is a minimal patch to add a User-Agent: header to outgoing requests.
I've tested it and found that it restored location search functionality.
I don't consider it a complete fix since it doesn't make the search URI
configurable.
Attempt a minimal fix for Debian #891325.
Index: git/panel-plugin/weather.c
===
--- git.orig/panel-plugin/weather.c 2018-02-24 17:08:19.734257691 +0100
+++ git/panel-plugin/weather.c 2018-02-24 18:04:11.807358994 +0100
@@ -1852,6 +1852,10 @@
g_object_set(data->session, SOUP_SESSION_TIMEOUT,
CONN_TIMEOUT, NULL);
+/* Set the user agent to something sensible */
+g_object_set(data->session, SOUP_SESSION_USER_AGENT,
+ PACKAGE_NAME "/" PACKAGE_VERSION " ", NULL);
+
/* Set the proxy URI from environment */
proxy_uri = g_getenv("HTTP_PROXY");
if (!proxy_uri)
Bug#891325: Acknowledgement (xfce4-weather-plugin: search function violates provider's usage policy)
The Nominatim Usage Policy at https://operations.osmfoundation.org/policies/nominatim/ reads in part: "Apps must make sure that they can switch the service at our request at any time (in particular, switching should be possible without requiring a software update). If at all possible, set up a proxy and also enable caching of requests." I think that argues for making the search URL configurable by the user at run time (especially when one also considers this other suggestion: "If your requirements are even larger you can install your own instance of Nominatim"). Maybe the User-Agent string could be made configurable as well (with a sensible default).
Bug#891325: xfce4-weather-plugin: search function violates provider's usage policy
Package: xfce4-weather-plugin Version: 0.8.9-1 Severity: serious The location search functionality is currently broken. On investigation, I find the following URL in the source code: http://nominatim.openstreetmap.org/search?q=%s&format=xml (where %s is replaced by the sanitized query string). Using this URL in Firefox returns plausible results. Searching in the plugin and capturing the wire traffic shows the following: GET /search?q=%s&format=xml HTTP/1.1 Host: nominatim.openstreetmap.org Connection: Keep-Alive (note the lack of a referrer or user agent in the request), to which the server responds with Access blocked Access blocked You have been blocked because you have violated the https://operations.osmfoundation.org/policies/nominatim/";>usage policy of OSM's Nominatim geocoding service. Please be aware that OSM's resources are limited and shared between many users. The usage policy is there to ensure that the service remains usable for everybody. Please review the terms and make sure that your software adheres to the terms. You should in particular verify that you have set a +valid referrer or a user agent that identifies your application, and that you are not overusing the service with massive bulk requests. If you feel that this block is unjustified or remains after you have adopted your usage, you may contact the Nominatim system administrator at nomina...@openstreetmap.org to have this block lifted. I understand that the plugin relies on libsoup for this. The documentation for soup_session_new_with_options mentions a SOUP_SESSION_USER_AGENT which one may want to consider using. Incidentally, libsoup supports TLS. An https:// URL would be an improvement, except for debugging (so one may want to add a toggle for this, with https being the default setting).
Bug#877683: [Pkg-dns-devel] Bug#877683: jessie version of dns-root-data lacks new ksk in root.ds
* Daniel Kahn Gillmor [2017-10-19 15:44:40 -0400]: > However, i'm not convinced that dnssec-dsfromkey is at fault, because i > think the versions of dnssec-dsfromkey in stretch and buster both have > the same behavior. It turns out the following change from version 2017020200 of the package was not included in the jessie backport: * Rewrite DS creation check to xml2 and ldnsutils, as neither xmllint nor bind9utils handle multiple DNSKEY in one file correctly
Bug#877683: jessie version of dns-root-data lacks new ksk in root.ds
* Sergio Gelato [2017-10-04 11:26:02 +0200]: > The corresponding package in stretch-updates looks OK. Could it be that the > one in jessie-updates needs to be built with a newer version of bind9utils? Indeed it seems that jessie's (including jessie-updates') dnssec-dsfromkey only processes the first key in the file.
Bug#877683: jessie version of dns-root-data lacks new ksk in root.ds
Package: dns-root-data Version: 2017072601~deb8u1 Severity: serious The version of this package that is currently in jessie-updates still only lists the old key 19036 in /usr/share/dns/root.ds. If I understood correctly, starting a week from now the root zone will only be signed with the new key 20326. /etc/init.d/dnsmasq in jessie relies on the contents of /usr/share/dns/root.ds to set the --trust-anchor argument to the daemon. The corresponding package in stretch-updates looks OK. Could it be that the one in jessie-updates needs to be built with a newer version of bind9utils?
Bug#854082: grub-installer: grub-xen fails to install on i386 or amd64 PV guest
* Cyril Brulebois [2017-02-04 00:27:17 +0100]: > If you're so inclined, here's an image with grub-installer 1.137, > including the change you've suggested: For the record: although I haven't used the image as-is, I have (a) proofread the diff between 1.136 and 1.137, and (b) successfully tested the same change in the following manner: -- on encountering the error in "Install the GRUB boot loader on a hard disk", skipped to "Execute a shell"; -- ran "nano /usr/bin/grub-install" and applied the fix; -- exited the shell and reran "Install the GRUB boot loader on a hard disk". For an amd64 guest this results in a bootable system. For an i386 one I run into #799840, but as far as the present bug is concerned this counts as a success.
Bug#854082: grub-installer: grub-xen fails to install on i386 or amd64 PV guest
Package: grub-installer Version: 1.136 Severity: serious The grub installation step reproducibly fails using the latest stretch d-i on both i386 and amd64 Xen PV guests. The logs indicate that grub-install is looking for /usr/lib/grub/i386-pc instead of /usr/lib/grub/i386-xen, and similarly on amd64. I think the problem was introduced by commit 66f75b7069aeba05eab776b5ac18dffa6874b5f3 . Shouldn't amd64:grub-xen and i386:grub-xen read amd64/*:grub-xen and i386/*:grub-xen, respectively, when matching against $ARCH:$grub_package ?
Bug#834654: heimdal 7.0.1 test failures
The i386 failures, at least, should be fixed in 7.0.2 and later. Issue #220 upstream, affecting all platforms where time()+0x7fff overflows time_t. I haven't tried your 7.0.2+dfsg1, only my own packaging of 7.0.3. Not sure about the hppa/powerpcspe and m68k failures, and I'm not in a position to test those architectures. I've found that debugging is a lot easier if one can see the detailed logs of the failing tests, as well as strace/ltrace output for the relevant command invocations.
Bug#822749: Heimdal FTBFS on 32-bit architectures
tag 822749 +patch thanks The attached patch (against the current tip of the Heimdal master branch) fixes the problem for me. >From 9772490720b7007b4d50fb062fb0d3e776ddb907 Mon Sep 17 00:00:00 2001 From: Sergio Gelato Date: Wed, 28 Sep 2016 15:15:12 +0200 Subject: [PATCH] Add missing type cast in lib/kadm5/log.c On 32-bit architectures with _FILE_OFFSET_BITS=64, sizeof(off_t) > sizeof(size_t) . LOG_HEADER_SZ is #define'd as an expression of type size_t, so in order to get the sign extension right we need -(off_t)LOG_HEADER_SZ instead of (off_t)(-LOG_HEADER_SZ). Fixes Debian bug #822749, PR 175. --- lib/kadm5/log.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/kadm5/log.c b/lib/kadm5/log.c index efe1f78..1f1fcc3 100644 --- a/lib/kadm5/log.c +++ b/lib/kadm5/log.c @@ -2337,7 +2337,7 @@ load_entries_cb(kadm5_server_context *server_context, * Seek back to the start of the record poayload so we can read the * whole record. */ -if (krb5_storage_seek(sp, -LOG_HEADER_SZ, SEEK_CUR) == -1) +if (krb5_storage_seek(sp, -(off_t)LOG_HEADER_SZ, SEEK_CUR) == -1) return errno; /* -- 2.1.4
Bug#830844: Pending fixes for bugs in the libauthen-krb5-perl package
> https://anonscm.debian.org/cgit/pkg-perl/packages/libauthen-krb5-perl.git/commit/?id=3558a41 You may have missed a documentation reference in Krb5.pm: --- =item get_krbhst(realm) Returns a list of the Kerberos servers from the specified realm. --- which raises the issue of how much Perl code out there may call Authen::Krb5::get_krbhst($realm) . As far as my own needs are concerned it's OK to drop this function, but it is an API change and may deserve a bump in the module's version number. Alternatively, one could lift the implementation of krb5_get_krbhst (in terms of profile_get_values, which is a public interface) from older libkrb5, or provide a new one if there are licensing issues. Of course this is more work and best left to upstream. As a stop-gap, maybe one could keep Authen::Krb5::get_krbhst but with a dummy implementation that always returns undef?
Bug#830844: Krb5.so fails to load: missing symbol krb5_free_krbhst
Package: libauthen-krb5-perl
Version: 1.9-4
Severity: serious
$ env PERL_DL_NONLAZY=1 perl -MAuthen::Krb5 -e '1;'
Can't load '/usr/lib/i386-linux-gnu/perl5/5.20/auto/Authen/Krb5/Krb5.so' for
module Authen::Krb5:
/usr/lib/i386-linux-gnu/perl5/5.20/auto/Authen/Krb5/Krb5.so: undefined symbol:
krb5_free_krbhst at /usr/lib/i386-linux-gnu/perl/5.20/DynaLoader.pm line 187.
at -e line 0.
Compilation failed in require.
BEGIN failed--compilation aborted.
This breaks test suites or anything else that sets PERL_DL_NONLAZY=1.
The problem is that this module uses an internal MIT Kerberos API that has
been removed. From Krb5.xs:
/*
* These are internal Kerberos library functions that aren't prototyped and
* that we probably shouldn't be calling. Prototype them with the arguments
* we expect and leave them for now pending an API cleanup.
*/
krb5_error_code krb5_free_krbhst(krb5_context, char * const *);
krb5_error_code krb5_get_krbhst(krb5_context, const krb5_data *, char ***);
And from the changelog (doc/CHANGES) for package krb5:
commit 81fde7e475b02986c1aff88766cc48882004d5dc
Author: Greg Hudson
Date: Fri Mar 22 16:00:48 2013 -0400
Get rid of krb5_{get,free}_krbhst
These functions were always internal. They haven't been used since
v5passwdd was eliminated in krb5 1.4.
Bug#794851: CVE-2015-0851: shibboleth-sp2 needs to be rebuilt against new xmltooling
Package: opensaml2 Version: 2.5.3-2 Severity: serious Tags: security The upstream security advisory for CVE-2015-0851 (see #793855) states in part: "Correcting this bug requires that the OpenSAML library be rebuilt against the corrected version of the XMLTooling-C library, which is normally assured by obtaining updates to both." This is presumably related to the fact that the patch to xmltooling touches preprocessor macros defined in . Specifically, the macro IMPL_INTEGER_ATTRIB is referenced several times on OpenSAML2 source code. The same macro also appears once in the source code for package shibboleth-sp2, making it also a candidate for recompilation. (Feel free to clone this bug if needed.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738927: mcelog: fails to install when CPU unsupported
I've just tested a patch and uploaded it to the corresponding Launchpad bug, https://bugs.launchpad.net/debian/+source/mcelog/+bug/1279293 . No, I don't think it's as simple as ignoring the failure in postinst. For one thing, that part of the postinst is generated automatically by debhelper. For another, if mcelog won't work as a trigger or daemon there is no point in the init script trying to start it at system boot time either. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
