Bug#914174: RFS: easy-rsa [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "easy-rsa": * Package name: easy-rsa Version : 3.0.5-1 Upstream Author : the Open-Source OpenVPN development community * URL : https://github.com/OpenVPN/easy-rsa/ * License : GPLv2 It builds those binary packages: easy-rsa - Simple shell based CA utility To access further information about this package, please visit the following URL: https://salsa.debian.org/maker-guest/easy-rsa/ Changes since the last upload: * New upstream version 3.0.5 * Updated d/README.Debian Regards, -- μ.
Bug#914172: [debian-mysql] Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1
On Tue, Nov 20, 2018 at 8:45 AM Jeremy Davis wrote: > As of the (automated) installation of today's MariaDB server security update > (10.1.37-0+deb9u1) > all of our user's LAMP based appliances uninstalled mariadb-server (i.e. > default-mysql-server, > mysql-server, mariadb-server-10.1 & mariadb-client-10.1) and thus most of web > based software > stopped functioning. Ouch. IMO apt shouldn't be run in such a way that packages get removed automatically though.. > We're still not sure exactly what caused this, but would like to note the > issue. Updated dependencies perhaps, in particular: > * Add libconfig-inifiles-perl to mariadb-client-10.1 depends to fix mytop Note this is just a guess. Gr, Olaf
Bug#896165: linux: request packaging of bpftool
On Fri, Apr 20, 2018 at 02:07:40PM +0200, Simon Horman wrote: > I would like to request packaging of bpftool which has been > included in upstream Linux tree since v4.15-rc1. I expect this can > be done in a similar manner to the way that perf, also present in > the upstream Linux kernel tree, is packaged. Please see https://salsa.debian.org/kernel-team/linux/merge_requests/72 It's not ready for merge, but hopefully it gets some good feedback and I can get it ready before long. I expect that applying the same patch to the 4.18 branch for sid will be straightforward. Is the plan for buster to include 4.18, or 4.19? Or something else? noah signature.asc Description: PGP signature
Bug#914173: surefire FTBFS
Source: surefire Version: 2.22.1-1 Severity: serious Tags: ftbfs Some recent change in unstable makes surefire FTBFS: https://tests.reproducible-builds.org/debian/history/surefire.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/surefire.html ... [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 34.876 s [INFO] Finished at: 2018-11-19T10:35:39-12:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:3.1.1:copy (main) on project surefire-junit47: Error copying artifact from /build/1st/surefire-2.22.1/debian/maven-repo/junit/junit/4.x/junit-4.x.jar to /build/1st/surefire-2.22.1/surefire-providers/surefire-junit47/target/endorsed/junit-4.x.jar: Failed to copy full contents from /build/1st/surefire-2.22.1/debian/maven-repo/junit/junit/4.x/junit-4.x.jar to /build/1st/surefire-2.22.1/surefire-providers/surefire-junit47/target/endorsed/junit-4.x.jar -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :surefire-junit47 dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/build/1st/surefire-2.22.1 -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/build/1st/surefire-2.22.1/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/surefire-2.22.1/debian -Dmaven.repo.local=/build/1st/surefire-2.22.1/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 make: *** [debian/rules:4: build] Error 2
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
On Tue, Nov 20, 2018 at 8:31 AM Mathieu Malaterre wrote: > > On Tue, Nov 20, 2018 at 8:19 AM Timo Aaltonen wrote: > > > > On 20.11.2018 9.04, Mathieu Malaterre wrote: > > > Package: mesa-common-dev > > > Version: 18.2.5-1 > > > Severity: serious > > > Tags: ftbfs > > > > > > OpenVDB fails to build from source because of: > > > > > > In file included from /usr/include/GL/gl.h:2055, > > > from viewer/Font.h:40, > > > from viewer/Font.cc:31: > > > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No > > > such file or directory > > > #include > > > ^~~ > > > compilation terminated. > > > > > > ref: > > > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=amd64&ver=5.2.0-5&stamp=154226&raw=0 > > > > > > It would be nice to fix this, upstream seems to have provided a patch: > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > > > That commit is in 18.2.5: > > > > commit 2645ea5817f4fd05905b8deda96c268cd69fa48c > > Author: Eric Engestrom > > Date: Tue Aug 7 12:56:25 2018 +0100 > > > > configure: install KHR/khrplatform.h when needed > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" > > Signed-off-by: Eric Engestrom > > Tested-by: Brad King > > Reviewed-by: Emil Velikov > > (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f) > > > > so something else is wrong. > > I must admit I was hoping for some help here. Here is what I see on my side: > > $ head -n 467 /usr/include/GL/glext.h | tail -1 > #include > > So this is a bit mysterious what is happening on all the buildds... As a side note, the experimental build of OpenVDB (same orig tarball as the one in sid) went find using the previous version of mesa: https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=amd64&ver=5.2.0-4&stamp=1542634335&raw=0 ... Get: 164 http://ftp.gr.debian.org/debian unstable/main amd64 mesa-common-dev amd64 18.1.9-1 [587 kB] ...
Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1
Package: mariadb-server-10.1 Version: unsure exactly - prior to today's security update Severity: grave Justification: renders package unusable Dear Maintainer, Please excuse me setting the severity as grave. Under the circumstance it seems appropriate, but I'm not 100% sure. FYI TurnKey Linux is a Debian derivative which builds "software appliances" using mostly Debian packages, many with upstream software pre-installed on top. It has Debian (and TurnKey) security updates automatically installed daily via cron-apt. As of the (automated) installation of today's MariaDB server security update (10.1.37-0+deb9u1) all of our user's LAMP based appliances uninstalled mariadb-server (i.e. default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1) and thus most of web based software stopped functioning. The expected outcome was that the packages were simply updated to the latest security update and continued functioning. We're still not sure exactly what caused this, but would like to note the issue. Assitance in ensuring that this sort of issue doesn't reoccur would also be welcomed. It only appears to be an issue if security only updates are installed. A full upgrade does not cause the same issue. The resolution is to simply reinstall default-mysql-server (which depends on mariadb-server-10.1 & mariadb-client-10.1 - mysql-server is an un-needed transitional package). Please note that this report was created on a freshly launched WordPress appliance (based on LAMP) with security updates installed on firstboot (and without the above menitoned fix applied). Please ask if you need any further info. Regards, Jeremy -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.1 depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii galera-3 25.3.19-2 ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii iproute2 4.9.0-1+deb9u1 ii libaio1 0.3.110-3 ii libc6 2.24-11+deb9u3 ii libdbi-perl 1.636-1+b1 ii libpam0g 1.1.8-3.6 ii libstdc++66.3.0-18+deb9u1 ii libsystemd0 232-25+deb9u4 ii lsb-base 9.20161125 ii lsof 4.89+dfsg-0.1 pn mariadb-client-10.1 ii mariadb-common10.1.37-0+deb9u1 ii mariadb-server-core-10.1 10.1.37-0+deb9u1 ii passwd1:4.4-4.1 ii perl 5.24.1-3+deb9u4 ii psmisc22.21-2.1+b2 ii rsync 3.1.2-1+deb9u1 ii socat 1.7.3.1-2+deb9u1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-server-10.1 recommends: pn libhtml-template-perl Versions of packages mariadb-server-10.1 suggests: ii bsd-mailx [mailx] 8.1.2-0.20160123cvs-4 pn mariadb-test pn netcat-openbsd pn tinyca
Bug#819693: missing bug report
Control: done 819693 1.0.4+nmu1 thanks This was done long ago, but for some reason the bug remained open, closing. -- IRC: gfa GPG: 0X44BB1BA79F6C6333
Bug#913950: squid: should improve handling of Debian packages
> > Dear Maintainer(s), > > the handling of Debian packages could be improved with some configuration > options > taken from the squid-deb-proxy package, see: > https://sources.debian.org/src/squid-deb-proxy/0.8.14+nmu1/squid-deb-proxy.conf > > This has been found out by Mike Gabriel; for details see > the discussion here: > https://bugs.debian.org/913886 > > If squid would improve the handling of Debian packages all users already using > squid could avoid installing squid-deb-proxy in addition. > Hi, Thank you for your interest in improving Squid in Debian. This is a topic I look into every so often to figure out how far Squid alone can go, and to do so without breaking people using squid-deb-proxy. The last time those checks were done was about July 2018 during the squid-4 packaging preparations. A brief aside on the topic of removing/replacing squid-deb-proxy: squid-deb-proxy provides relatively large amount of extra integration setup to add Avahi daemon(s) reporting where to find the Squid proxy. As well as apt configuration to enable auto-proxy detection and use the Avahi service. There may be more subtle things as well. A key factor is that much of this integration occurs on the client machines without any proxy installed there. Merging those integration actions would add a conflict between squid and squid-deb-proxy. As well as require additional binary packages to be produced by the pkg-squid team for the client machines integration parts. That role IMHO is already played well by squid-deb-proxy despite its maintainer not being in the pkg-squid team. So I see little gain and much pain attempting to replace squid-deb-proxy. Anyhow, back to the proposed config settings: > So please consider to adjust d/debian.conf like proposed by Mike. > > diff --git a/debian/debian.conf b/debian/debian.conf > index 7ac16c97..7fa82301 100644 > --- a/debian/debian.conf > +++ b/debian/debian.conf > @@ -9,3 +9,29 @@ logfile_rotate 0 > # localhost to use the proxy on new installs > # > #http_access allow localnet > + > +# Begin: Improve handling of Debian packages (taken from squid-deb-proxy) > +# we need a big cache, some debs are huge > +maximum_object_size 512 MB > + > +# tweaks to speed things up > +cache_mem 200 MB First surprise is this line above. Squid packages as far back as Lenny have had a default cache_mem setting of 256 MB. So this is actually a decrease in capacity of the fastest accessible cache type (RAM). > +maximum_object_size_in_memory 10240 KB > + Which is a 512Kb -> 10 MB conflicts a little with the earlier setting to decrease the size of objects stored in there to 10MB. Also, Squid understand units up to TB. So: s/10240 KB/10 MB/ would be clearer and still work. > +# refresh pattern for debs and udebs > +refresh_pattern deb$ 129600 100% 129600 > +refresh_pattern udeb$ 129600 100% 129600 > +refresh_pattern tar.gz$ 129600 100% 129600 > +refresh_pattern tar.xz$ 129600 100% 129600 > +refresh_pattern tar.bz2$ 129600 100% 129600 > + Squid is much more often a gateway to the generic web or internal LAN environments - or at least dual-purpose with the apt package caching. These tarball settings specifically would affect content well beyond Debian repositories. Which is more a problem than benefit when one considers what (2) below means about Debian repos not using these pattern settings. So IMHO, the above are not appropriate for widespread default inclusion. It is better to have admin explicitly opt-in to using such rules. for example; by installing the squid-deb-proxy or similar package which drops in a squid config snippet. > +# always refresh Packages and Release files > +refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims > +refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims > +refresh_pattern \/InRelease$ 0 0% 0 refresh-ims > +refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims > + The parameters refresh_pattern supplies are used as defaults for the caching heuristic algorithm(s). The values on all these lines are *only* obeyed when the origin server omits a parameter needed by the caching freshness algorithm from its HTTP response message. In particular that means that when evaluating the utility of these rules it is necessary to first analyze the origin service responses for each of the relevant APT request messages to determine what caching parameters it is supplying and which it is omitting. When I have done that analysis for Debian official repositories those servers *did* consistently provide the necessary cache parameters to Squid. So for at least those repo servers these refresh_pattern rules would do nothing beyond that 'refresh-ims' change in behaviour. On the other hand my local reprepro installation does not always provide those details. Particularly for the Packages requests. But does so in a way which these config lines are insufficient to prevent immediate re-fetch of the full content. Thus I am
Bug#914168: python3-epc: requires module sexpdata but does not depend on it
Package: python3-epc Version: 0.0.5-1 Severity: important Tags: patch Dear maintainer, I just installed python3-epc on a Debian Sid system. During runtime I got the following error message: ``` import epc.server File "/usr/lib/python3/dist-packages/epc/server.py", line 23, in from .handler import EPCHandler, ThreadingEPCHandler File "/usr/lib/python3/dist-packages/epc/handler.py", line 21, in from sexpdata import loads, dumps, Symbol, String ModuleNotFoundError: No module named 'sexpdata' ``` Apparently, the epc module requires the sexpdata module, but its package is missing the appropriate dependency. epc/handler.py: > from sexpdata import loads, dumps, Symbol, String The error was resolved after manually installing the `python3-sexpdata` package. Please add the package `python3-dexpdata` to the Depends-field of `python3-epc` and `python-sexpdata` to `python-epc`. Greetings Jack signature.asc Description: OpenPGP digital signature
Bug#914171: neutron-vpnaas: [INTL:ru] Russian debconf translation
Source: neutron-vpnaas Severity: wishlist Tags: l10n patch Dear Maintainer, please find attached Russian debconf template translation for neutron-vpnaas. Regards, Lev -- 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.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled # Russian debconf translation for neutron-vpnaas # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the neutron-vpnaas package. # Lev Lamberov , 2018 # msgid "" msgstr "" "Project-Id-Version: neutron-vpnaas\n" "Report-Msgid-Bugs-To: neutron-vpn...@packages.debian.org\n" "POT-Creation-Date: 2018-10-31 14:45+0100\n" "PO-Revision-Date: 2018-11-20 12:20+0500\n" "Language-Team: Debian L10N Russian \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.2\n" "Last-Translator: Lev Lamberov \n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<12 || n%100>14) ? 1 : 2);\n" "Language: ru\n" #. Type: boolean #. Description #: ../neutron-vpnaas-common.templates:1001 msgid "Run default configuration for neutron-vpnaas ?" msgstr "Запустить настройки по умолчанию для neutron-vpnaas?" #. Type: boolean #. Description #: ../neutron-vpnaas-common.templates:1001 msgid "" "Neutron-vpnaas will be configured to use strongswan and vpnaas l3 extension. " "If you want to run now, please make sure you have configured database." "connection in neutron.conf:" msgstr "" "Neutron-vpnaas будет настроен на использование strongswan и расширения " "vpnaas l3. Если вы хотите запустить службу сейчас, то убедитесь в том, что " "вы настроили database.connection в файле neutron.conf:" #. Type: boolean #. Description #: ../neutron-vpnaas-common.templates:1001 msgid "" "If you don't choose this option, no database migration will be run and no " "plugin will be enabled, these things you have to do manually." msgstr "" "Если вы не выбрали данную опцию, то миграция базы данных не будет запущена, " "и дополнения не будут включены. Вам придётся сделать это вручную." #. Type: boolean #. Description #: ../neutron-vpnaas-common.templates:1001 msgid "" "You can change this setting later on by running \"dpkg-reconfigure -plow " "neutron-vpnaas-common\"." msgstr "" "Вы можете изменить это позже, запустив команду \"dpkg-reconfigure -plow " "neutron-vpnaas-common\"."
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
On Tue, Nov 20, 2018 at 8:19 AM Timo Aaltonen wrote: > > On 20.11.2018 9.04, Mathieu Malaterre wrote: > > Package: mesa-common-dev > > Version: 18.2.5-1 > > Severity: serious > > Tags: ftbfs > > > > OpenVDB fails to build from source because of: > > > > In file included from /usr/include/GL/gl.h:2055, > > from viewer/Font.h:40, > > from viewer/Font.cc:31: > > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No > > such file or directory > > #include > > ^~~ > > compilation terminated. > > > > ref: > > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=amd64&ver=5.2.0-5&stamp=154226&raw=0 > > > > It would be nice to fix this, upstream seems to have provided a patch: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=107511 > > That commit is in 18.2.5: > > commit 2645ea5817f4fd05905b8deda96c268cd69fa48c > Author: Eric Engestrom > Date: Tue Aug 7 12:56:25 2018 +0100 > > configure: install KHR/khrplatform.h when needed > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 > Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" > Signed-off-by: Eric Engestrom > Tested-by: Brad King > Reviewed-by: Emil Velikov > (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f) > > so something else is wrong. I must admit I was hoping for some help here. Here is what I see on my side: $ head -n 467 /usr/include/GL/glext.h | tail -1 #include So this is a bit mysterious what is happening on all the buildds...
Bug#914170: neutron-fwaas: [INTL:ru] Russian debconf translation
Source: neutron-fwaas Severity: wishlist Tags: l10n patch Dear Maintainer, please find attached Russian debconf template translation for neutron-fwaas. Regards, Lev -- 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.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled # Russian debconf translation for neutron-fwaas # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the neutron-fwaas package. # Lev Lamberov , 2018 # msgid "" msgstr "" "Project-Id-Version: neutron-fwaas\n" "Report-Msgid-Bugs-To: neutron-fw...@packages.debian.org\n" "POT-Creation-Date: 2018-10-25 13:59+\n" "PO-Revision-Date: 2018-11-20 12:21+0500\n" "Language-Team: Debian L10N Russian \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.2\n" "Last-Translator: Lev Lamberov \n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<12 || n%100>14) ? 1 : 2);\n" "Language: ru\n" #. Type: boolean #. Description #: ../neutron-fwaas-common.templates:1001 msgid "Run default configuration for neutron-fwaas ?" msgstr "Запустить настройки по умолчанию для neutron-fwaas?" #. Type: boolean #. Description #: ../neutron-fwaas-common.templates:1001 msgid "" "Neutron-fwaas will be configured to use ovs and firewall_v2. If you want to " "run now, please make sure you have configured database.connection in neutron." "conf:" msgstr "" "Neutron-vpnaas будет настроен на использование ovs и firewall_v2. Если вы " "хотите запустить службу сейчас, то убедитесь в том, что вы настроили " "database.connection в файле neutron.conf:" #. Type: boolean #. Description #: ../neutron-fwaas-common.templates:1001 msgid "" "If you don't choose this option, no database migration will be run and no " "plugin will be enabled, these things you have to do manually." msgstr "" "Если вы не выбрали данную опцию, то миграция базы данных не будет запущена, " "и дополнения не будут включены. Вам придётся сделать это вручную." #. Type: boolean #. Description #: ../neutron-fwaas-common.templates:1001 msgid "" "You can change this setting later on by running \"dpkg-reconfigure -plow " "neutron-fwaas-common\"." msgstr "" "Вы можете изменить это позже, запустив команду \"dpkg-reconfigure -plow " "neutron-fwaas-common\"."
Bug#914169: google-android-installers: [INTL:ru] Russian debconf translation
Source: google-android-installers Severity: wishlist Tags: l10n patch Dear Maintainer, please find attached Russian debconf template translation for google-android-installers. Regards, Lev -- 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.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled # Russian debconf translation for google-android-installers # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the google-android-platform-installers package. # Lev Lamberov , 2018 # msgid "" msgstr "" "Project-Id-Version: google-android-platform-installers\n" "Report-Msgid-Bugs-To: google-android-platform-installers@packages.debian." "org\n" "POT-Creation-Date: 2016-07-19 20:36+\n" "PO-Revision-Date: 2018-11-10 11:26+0500\n" "Language-Team: Debian L10N Russian \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Poedit 2.2\n" "Last-Translator: Lev Lamberov \n" "Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n" "%10<=4 && (n%100<12 || n%100>14) ? 1 : 2);\n" "Language: ru\n" #. Type: select #. Description #: ../google-android-platform-24-installer.templates:1001 #: ../google-android-platform-23-installer.templates:1001 #: ../google-android-platform-22-installer.templates:1001 msgid "Mirror to download packages ?" msgstr "Зеркало для загрузки пакетов?" #. Type: select #. Description #: ../google-android-platform-24-installer.templates:1001 #: ../google-android-platform-23-installer.templates:1001 #: ../google-android-platform-22-installer.templates:1001 msgid "" "Please select your prefered mirror to download Google's Android packages " "from." msgstr "" "Выберите предпочитаемое зеркало для загрузки пакетов Google Android."
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
On 20.11.2018 9.04, Mathieu Malaterre wrote: > Package: mesa-common-dev > Version: 18.2.5-1 > Severity: serious > Tags: ftbfs > > OpenVDB fails to build from source because of: > > In file included from /usr/include/GL/gl.h:2055, > from viewer/Font.h:40, > from viewer/Font.cc:31: > /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No > such file or directory > #include > ^~~ > compilation terminated. > > ref: > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=amd64&ver=5.2.0-5&stamp=154226&raw=0 > > It would be nice to fix this, upstream seems to have provided a patch: > > https://bugs.freedesktop.org/show_bug.cgi?id=107511 That commit is in 18.2.5: commit 2645ea5817f4fd05905b8deda96c268cd69fa48c Author: Eric Engestrom Date: Tue Aug 7 12:56:25 2018 +0100 configure: install KHR/khrplatform.h when needed Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511 Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)" Signed-off-by: Eric Engestrom Tested-by: Brad King Reviewed-by: Emil Velikov (cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f) so something else is wrong. -- t
Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory
Package: mesa-common-dev Version: 18.2.5-1 Severity: serious Tags: ftbfs OpenVDB fails to build from source because of: In file included from /usr/include/GL/gl.h:2055, from viewer/Font.h:40, from viewer/Font.cc:31: /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory #include ^~~ compilation terminated. ref: https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=amd64&ver=5.2.0-5&stamp=154226&raw=0 It would be nice to fix this, upstream seems to have provided a patch: https://bugs.freedesktop.org/show_bug.cgi?id=107511
Bug#842534: libmodbus: new upstream release - 3.1.4
Hi Marc, On Mon, 19 Nov 2018 08:46:38 +0100 Marc Haber wrote: > On Sat, Sep 08, 2018 at 12:35:10PM +0200, Ivo De Decker wrote: > > I didn't look into the new version yet, because it is still marked as > > 'unstable' by upstream. > > Where is this marker? All I see on the upstream github page is a > release numbered 3.1.4, which is over two years old. > > > If you prefer to have it in debian anyway, it would be > > good to know how upstream is planning to handle API/ABI changes in the > > unstable branch. If there are incompatible changes without the necessary > > changes to the library version, that would be harder to maintain. > > Please consider talking to the upstream of your package about these > issues in case you want to continue maintaining the package. It is not a > good idea to have a five year old version that has been superseded twice > by new upstream releases in Debian buster. > I've packaged new version of libmodbus [1], and Ivo gave the green light to me yesterday. Hence, I will upload new version of libmodbus in these days. [1] https://salsa.debian.org/debian/libmodbus SZ Lin > Greetings > Marc > > > -- SZ Lin (林上智) , http://people.debian.org/~szlin Debian Developer 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9
Bug#914059: git-remote-gcrypt: fails without mentioning that the fingerprint for the RSA key sent by the remote host has changed
Hi Sean and moire, Sean Whitton: > I think the best option might simply be if git-remote-gcrypt > stops hiding the output from git when this failure occurs? Agreed (modulo I've not seen how that would look like yet; happy to test patches :) Actually I would go as far as: " stop hiding the output from git when any failure occurs that would produce this error: gcrypt: Repository not found: "my encrypted git repo" gcrypt: ..but repository ID is set. Aborting. " Rationale: one also gets this not-quite-useful error message in other failure modes such as Internet connectivity issues; then, in my experience, users think that either they have misconfigured things the Git remote URL on their side, or the repo disappeared on the server side; in both cases, in practice this results to folks sending non-actionable support request to project engineers or sysadmins, which is somewhat frustrating to everyone involved. Cheers, -- intrigeri
Bug#908681: libsane1: pointless package rename
Hi, is this related to conflicts with the gnome package in sid? (apt dist-upgrade) To be removed: colord gnome gnome-color-manager gnome-control-center gnome-core libsane1 libsane1:i386 sane-utils simple-scan task-gnome-desktop Held back: libtiff5 Upgrade: libsane-common Regards, Nils signature.asc Description: This is a digitally signed message part
Bug#859123: automating process for publishing DLAs on the website
Hi, Пн 19 ноя 2018 @ 19:07 Antoine Beaupré : > Few of you might already know that DLAs are *supposed* to show up in > there as well, and did for a while. For example, here's a few DLAs in > 2014: > > https://www.debian.org/security/2014/ > > The process broke down a while back, and reasons don't matter. We need > to figure out how to fix this. > > So I opened #859122 to import the missing DLAs and I've made good > progress. > > But I've opened this bug report (#859123) to fix the process. So far, > the idea we had was to make LTS contributors submit a patch to the > website as part of the DLA publication process. You'd run the little > "parse-dla.pl" script which would create two files in the webwml git > repository, separate from the security tracker! that's where the > debian.org website lives.. Then you'd commit those and send a merge > request to the project (or just push if you have the rights). The > webmaster folks seemed to be open to grant us access to the repo to > remove friction as well.. > > How does that sound? > > Another thing I thought we could do would be to hook that script into a > mailbox that would receive mail from the debian-lts-announce list and > automatically publish the results into git. But so far my efforts at > automating things on Debian infrastructure have mostly failed, so I'm > not sure it's the way to go. Besides, the parse-dsa.pl script isn't > exactly solid, and don't like the idea of parsing arbitrary input like > this without a human oversight. But it would certainly reduce friction > to a minimum, which I like. > > Any other ideas? DSAs are also imported by hand with the help of "parse-advisory.pl", there are always some folks in webwml or security team who can do this. The difference between DSAs and DLAs is that the former is somewhat standartized and can be parsed semi-automatically. It is not always the case with the latter, that is the mentioned "parse-dla.pl" may just throw an error because of some unusual markup or something. But let me stress that even in case of DSAs parsing does not always performs well, and adding a new DSA to the webwml requires checking it beforehand and sometimes fixing html/wml tags. I hope that LTS team _together_ with the Debian Security team will be able to find a common concise markup format which will become a standard both for DSAs and DLAs, and which could be easily and unambiguously parsed, so automatic processing would be possible. Regards, Lev
Bug#913845: closed by Abhijith PA (Bug#913845: fixed in httping 2.5-4)
On 20 November 2018 2:17:30 AM IST, Helmut Grohne wrote: >Control: reopen -1 > >On Sat, Nov 17, 2018 at 12:09:08PM +, Debian Bug Tracking System >wrote: >>[Helmut Grohne] >>* Fix FTCBFS: Export a cross compiler for ./configure and make. >> (Closes: #913845) > >You applied the patch partially. Without including buildtools.mk, CC >simply becomes "cc" and that's wrong Sorry, my bad. I manually handpicked the lines to avoid full patch. I will upload tonight itself. >If you dislike buildtools.mk, you >can use the following: > >include /usr/share/dpkg/architecture.mk >ifeq ($(origin CC),default) >CC = $(DEB_HOST_GNU_TYPE)-gcc >endif > >Helmut Really thanks for looking at the issue. Abhijith. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#914166: gitlab: CVE-2018-19359: Unauthorized service template creation
Source: gitlab Version: 10.8.7+dfsg-1 Severity: grave Tags: security upstream Hi, The following vulnerability was published for gitlab. CVE-2018-19359[0]: Unauthorized service template creation 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-19359 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19359 [1] https://about.gitlab.com/2018/11/19/critical-security-release-gitlab-11-dot-4-dot-6-released/ Regards, Salvatore
Bug#914158: kpartx package includes wrong del-part-nodes.rules udev file
Control: tag -1 +pending Hello Jean-François, Thank you for the bug report. I have fixed it accordingly and it will be part of the next upload very soon. This bug will get auto-closed once the fixed package is part of the Debian Unstable distribution. Thanks, Ritesh On Mon, 2018-11-19 at 16:30 -0800, Jean-François Remy wrote: > Package: kpartx > Version: 0.7.8-2 -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#914165: virtualbox: Please ship rdesktop-vrdp utility
Package: virtualbox Version: 5.2.22-dfsg-1 Severity: wishlist Hi, VirtualBox supports remote display of VMs using the (V)RDP protocol, and in particular the VRDP protocol has extensions like remote USB that don't appear to be available in RDP clients other than the 'rdesktop-vrdp' one that VirtualBox ships. If the Debian virtualbox package could ship the rdesktop-vrdp utility it would be appreciated. The source package is already building it. The patch below will ship it in the virtualbox binary package. Thanks! diff --git a/debian/virtualbox.install b/debian/virtualbox.install index fc8a83be1..29d9df584 100644 --- a/debian/virtualbox.install +++ b/debian/virtualbox.install @@ -37,3 +37,6 @@ out/bin/sdk/bindings/xpcom/python /usr/lib/virtualbox/sdk/bindings/xpcom out/bin/VBoxCreateUSBNode.sh /lib/udev out/bin/VBoxSysInfo.sh /usr/share/virtualbox debian/vboxweb.service /lib/systemd/system/ + +out/bin/rdesktop-vrdp /usr/bin +out/bin/rdesktop-vrdp-keymaps /usr/share/virtualbox -- Robert Edmonds edmo...@debian.org
Bug#913037: (no subject)
retitle 913037 "test dulwich.tests.test_porcelain.PushTests.test_simple contains race condition" thanks This is not a python3.7-specific issue, but a test that contains a race condition that means it occasionally fails. This is reproducible on other python versions as well (when running the test repeatedly). signature.asc Description: PGP signature
Bug#914164: missing lua 5.3 package
Package: lua-basexx Version: 0.3-2 This package seems to be missing a lua 5.3 module: # dpkg -L lua-basexx /. /usr /usr/share /usr/share/doc /usr/share/doc/lua-basexx /usr/share/doc/lua-basexx/changelog.Debian.gz /usr/share/doc/lua-basexx/copyright /usr/share/lua /usr/share/lua/5.1 /usr/share/lua/5.1/basexx.lua /usr/share/lua/5.2 /usr/share/lua/5.2/basexx.lua
Bug#914163: lintian: False positive: source-only-upload-to-non-free-without-autobuild on source+binary upload
Package: lintian Version: 2.5.112 Severity: normal Dear Maintainer, lintian incorrectly reports source-only-upload-to-non-free-without-autobuild when the changes file includes both source and binary package files. $ lintian bison-doc_3.2.1-1_amd64.changes E: bison-doc source: source-only-upload-to-non-free-without-autobuild This bug is causing FTP master to reject the upload automatically. *** bison-doc_3.2.1-1_amd64.changes -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 18 Nov 2018 20:57:05 -0800 Source: bison-doc Binary: bison-doc Architecture: source all Version: 1:3.2.1-1 Distribution: experimental Urgency: medium Maintainer: Chuan-kai Lin Changed-By: Chuan-kai Lin Description: bison-doc - Documentation for the Bison parser generator Changes: bison-doc (1:3.2.1-1) experimental; urgency=medium . * New upstream version. * Update Standards-Version to 4.2.1.0 (no change required). Checksums-Sha1: a430d4bb439057d938ace11cb9fae45201bf822e 1804 bison-doc_3.2.1-1.dsc ed2eb78718e3d9a724a85daf08e9c3d5026a67f0 290016 bison-doc_3.2.1.orig.tar.xz 5b88a38d23093157a1a706a888400584068deee9 3640 bison-doc_3.2.1-1.debian.tar.xz 3f2611e14063d4c72b7d4dec7027db271387e427 1256504 bison-doc_3.2.1-1_all.deb 1cf855882baab7511c2606604a1ce8bc90458068 8010 bison-doc_3.2.1-1_amd64.buildinfo Checksums-Sha256: 9e1e9825d2f90668fe293c3814669059408dc1eb3a09711c1b5c42a1c603b402 1804 bison-doc_3.2.1-1.dsc 420699c64016402ed3bd369212c214314607042c41889f8fa48540fe0cb39339 290016 bison-doc_3.2.1.orig.tar.xz 7f8b682f87ea14dafc87abff69dbfc1c172aa8730cefa444806563afa5011b91 3640 bison-doc_3.2.1-1.debian.tar.xz d653e0f15db0248ee911607f641b783b889e984f333266e620c334790d43eef6 1256504 bison-doc_3.2.1-1_all.deb 8c03b1ef2d7fb0373afa3af973ef7eab0ecea4d693908e601c8f8072e9532c7c 8010 bison-doc_3.2.1-1_amd64.buildinfo Files: a159b86a790411cd1fb5bb9b898882de 1804 non-free/doc optional bison-doc_3.2.1-1.dsc ed73e1f22f8fb8f0189cacc82bc93d3b 290016 non-free/doc optional bison-doc_3.2.1.orig.tar.xz 5c8bff5a0c101db7847d8e579317670d 3640 non-free/doc optional bison-doc_3.2.1-1.debian.tar.xz 5dfe1ade63de4ebc62815b22039bb3c0 1256504 non-free/doc optional bison-doc_3.2.1-1_all.deb 407989dc30bf54d3e8271a2b0e5b2056 8010 non-free/doc optional bison-doc_3.2.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEpjo/UW6i/KKi+2ONAbOplSquRxMFAlvyRG4RHGNrbGluQGRl Ymlhbi5vcmcACgkQAbOplSquRxMRqBAA53gYlK4OeC/T+ZmpRDw+wsEAbrJgD7n9 RgCyxPPti/i2jhGyeb4fKoV8EArcmFWXAxiELirjVqDTuWnuYaxcnODiv+l/l9nE JW3ekBlyHG0mgu7E/NISk/QIi/bIvqiLkxeeuJBxo/KWgBR4G2WF++NhaDsqOKC/ gAnjxBBNNHXDo9KIiAh1HDMGvhJ21KQ5Wsjyop5+iWY0VKzmSvh6TAKD+jzLpdzt nio/vCD32udw96dMmWKV0IWbL2hsBOvTrsYDNesrMP5rLUeYdoQIVEmka5qYz/7W /yo1PGRRYdDC63pprHKJv8dz/r2QCm0eWJvvJP5uV9hBT5wfFPX+IyU925tw1Ohr CkT9+fRZpZAg+k8mhN9OHsg6pIgI1OZiTC19UI17Uj4H7kNwdC54xdYj/IY0cv8W pAU4YsETalwNQoXjEHosP1piMv0vJaB1g/AMraBXdrE8CY4LaWcieAOr29RklXbk xj/vMIUQFV8guxTlX5+QeEgJwJp+T3sIOdM4/HvnQAufMNLqSRcSumKgFKLi1d/y yQltoy6jCtvtkoc0kZJP1wlVNqAyE6oqmtxsR+q5W6DLw7EpTJmIh03aEO20RxK9 o6Zs4vbmetanpXcUWtqazDnAGcv6hwk69yac91xN8lTz1MsamFxJMBHQ63v59wwq s8uEmP5I+Cs= =YXGU -END PGP SIGNATURE- -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/2 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 lintian depends on: ii binutils 2.31.1-7 ii bzip2 1.0.6-9 ii diffstat 1.61-1+b1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-9 ii gpg2.2.10-3 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.75+repack-1 ii man-db 2.8.4-3 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.28.0-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions
Bug#914065: nheko FTBFS: Could not find a package configuration file provided by "MatrixClient"
On Mon, 19 Nov 2018 02:31:47 +0100, Axel Beckert said: > The cause for this might be much earlier: > [...] > CMake Warning at CMakeLists.txt:200 (export): > Cannot create package registry file: > > /sbuild-nonexistent/.cmake/packages/MatrixClient/217899eff9ecbd2457b9e7580f99b5aa > No such file or directory Yup, I noticed that too. I don't know much about CMake, so if anyone has any insights, it would be much appreciated. -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#912527: [Openjdk] Bug#912527: openjdk-8-jdk: please update to support class file version 64
On Wed, Oct 31, 2018 at 11:57 PM Norbert Preining wrote: > $ java -jar myprog.jar > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.UnsupportedClassVersionError: > javafx/event/EventTarget has been compiled by a more recent version of the > Java Runtime (class file version 54.0), this version of the Java Runtime only > recognizes class file versions up to 52.0 > ... Please note that differently from Oracle JDK the OpenJDK project does not contain any classes for javafx. In Debian these classes are provided by the openjfx package. In particular the class javafx/event/EventTarget can be found in the libopenjfx-java binary package inside the /usr/share/java/javafx-base-11.jar file. >From your system informaton I can see you are running sid. The openjfx version in sid is 11+26-5, which is not compatible with openjdk-8 [see https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md]. It depends and is only usable with openjdk-10 or openjdk-11. > OTOH, if I use jdk8 from upstream: > $ which java > /home/norbert/Java/jdk1.8.0_192/bin/java > $ java -version > java version "1.8.0_192-ea" > Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04) > Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode) > $ java -jar myprog.jar > ... > > There are no problems. This is because the Oracle JDK packages JavaFX in its binary, it is not using the openjfx package from Debian, thus it works. > > Would it be possible to update jdk8 in Debian to support that? The only way for Debian to support that would be for it to have something like a separated openjfx-8 package that was compiled with openjdk-8. Somebody would have to be willing to support that but I am not sure if openjdk-8 will even be included in buster. The openjfx maintainer can probably provide a more insights into that. -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#914162: sslsniff: unusual HTTP header capitalization breaks sslsniff
Package: sslsniff Version: 0.8-8+b1 Severity: important Tags: patch Dear Maintainer, sslsniff incorrectly uses case sensitive comparisons when parsing HTTP headers, for example "Accept-Encoding", "Connection", "Keep-Alive" etc. Servers can and do send headers with different capitalization (for example Oracle-iPlanet-Web-Server is known to do this). If such unusual capitalization is used by the server, sslsniff doesn't work right since it fails to detect the header. I except sslsniff to function even though headers of unusual capitalization are met. Patch fixing this issue has been merged to HEAD in 2011 already: https://github.com/moxie0/sslsniff/pull/3/commits/f8c4274d1bfc3c2eca241d65f96de746bb0065e0 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-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/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sslsniff depends on: ii libboost-filesystem1.67.0 1.67.0-10 ii libboost-system1.67.0 1.67.0-10 ii libboost-thread1.67.0 1.67.0-10 ii libc6 2.27-8 ii libgcc11:8.2.0-9 ii liblog4cpp5v5 1.1.3-1 ii libssl1.1 1.1.1-2 ii libstdc++6 8.2.0-9 sslsniff recommends no packages. sslsniff suggests no packages. -- no debconf information
Bug#914161: zaqar-ui: Add explicit built dependency on python3-django-horizon
Package: zaqar-ui Version: 5.0.0-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Dear Maintainer, The zaqar-ui build/tests require python3-django-horizon to be present, which only works in Debian because it's pulled in transitively. In Ubuntu, however, it is not, which caused the build to fail there. We should add an explicit dependency on this package since it's needed for the build. In Ubuntu, the attached patch was applied to achieve the following: * Add explicit build dependency on python3-django-horizon to fix FTBFS. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-10-generic (SMP w/8 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 diff -Nru zaqar-ui-5.0.0/debian/control zaqar-ui-5.0.0/debian/control --- zaqar-ui-5.0.0/debian/control 2018-09-05 14:49:39.0 -0400 +++ zaqar-ui-5.0.0/debian/control 2018-11-19 22:08:07.0 -0500 @@ -18,6 +18,7 @@ python3-coverage, python3-django (<< 2:2), python3-django-babel (>= 0.6.2), + python3-django-horizon, python3-django-nose (>= 1.4.4), python3-hacking, python3-mock,
Bug#911876: asyncpg FTBFS: tests fail
Package: asyncpg
Version: 0.17.0-1
Followup-For: Bug #911876
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* d/p/fix-large-oid-test.patch: Grab patch from upstream Git to fix large
OID test with PostgreSQL 11.
Thanks for considering the patch.
Logan Rosen
-- System Information:
Debian Release: buster/sid
APT prefers cosmic-updates
APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-10-generic (SMP w/8 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
diff -Nru asyncpg-0.17.0/debian/patches/fix-large-oid-test.patch
asyncpg-0.17.0/debian/patches/fix-large-oid-test.patch
--- asyncpg-0.17.0/debian/patches/fix-large-oid-test.patch 1969-12-31
19:00:00.0 -0500
+++ asyncpg-0.17.0/debian/patches/fix-large-oid-test.patch 2018-11-19
22:00:06.0 -0500
@@ -0,0 +1,47 @@
+From ddb0ec2918c370ba6fc2f569835fd02078132058 Mon Sep 17 00:00:00 2001
+From: Elvis Pranskevichus
+Date: Mon, 22 Oct 2018 19:07:06 -0400
+Subject: [PATCH] Fix large OID test under PostgreSQL 11
+
+PostgreSQL 11 seems to be automatically creating array types for domains
+with OIDs that _precede_ the OID of the array element type, so
+the large OID test trips over with an off-by-one assertion error.
+---
+ tests/test_codecs.py | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/tests/test_codecs.py b/tests/test_codecs.py
+index 9aac5ea..5498b40 100644
+--- a/tests/test_codecs.py
b/tests/test_codecs.py
+@@ -1727,10 +1727,12 @@ def _decoder(value):
+
+ @unittest.skipIf(os.environ.get('PGHOST'), 'using remote cluster for testing')
+ class TestCodecsLargeOIDs(tb.ConnectedTestCase):
++LARGE_OID = 2147483648
++
+ @classmethod
+ def setup_cluster(cls):
+ cls.cluster = cls.new_cluster(pg_cluster.TempCluster)
+-cls.cluster.reset_wal(oid=2147483648)
++cls.cluster.reset_wal(oid=cls.LARGE_OID)
+ cls.start_cluster(cls.cluster)
+
+ async def test_custom_codec_large_oid(self):
+@@ -1739,7 +1741,15 @@ def setup_cluster(cls):
+ oid = await self.con.fetchval('''
+ SELECT oid FROM pg_type WHERE typname = 'test_domain_t'
+ ''')
+-self.assertEqual(oid, 2147483648)
++
++expected_oid = self.LARGE_OID
++if self.server_version >= (11, 0):
++# PostgreSQL 11 automatically create a domain array type
++# _before_ the domain type, so the expected OID is
++# off by one.
++expected_oid += 1
++
++self.assertEqual(oid, expected_oid)
+
+ # Test that introspection handles large OIDs
+ v = await self.con.fetchval('SELECT $1::test_domain_t', 10)
diff -Nru asyncpg-0.17.0/debian/patches/series
asyncpg-0.17.0/debian/patches/series
--- asyncpg-0.17.0/debian/patches/series1969-12-31 19:00:00.0
-0500
+++ asyncpg-0.17.0/debian/patches/series2018-11-19 22:00:15.0
-0500
@@ -0,0 +1 @@
+fix-large-oid-test.patch
Bug#754129: Lutris package
I know a lot of time passed by, but I am not sure if the rejection reason for lutris was factually correct. And the uploader didn't follow up with that. I tested recent deb packages and sources of upstream lutris, including git versions, and there are no non-free components in source, used during build or in binary package. I also launched and use lutris, and it did not download or used any non free components. The fact that lutris can be used with non free software, isn't any different than apt or wget can be used with non free software. It definitively classifies into 'main'. Not 'contrib'. The only (fixable) issue is that binary package depends on 'unrar', which is non-free, and packages in main afaik can't depend on non-free ones with alternatives. It should instead use Recommends, or use Depends: unrar-free | unrar, or just unrar-free should suffice probably. PS. It is obviously possible that in 2014, situation was different. Best regards, Witold
Bug#914155: netfilter-persistent save modprobe ERROR
Hi thanks for your report, this is a problem I introduced by mistake in 07df20dcbff91 :( -- IRC: gfa GPG: 0X44BB1BA79F6C6333
Bug#913708: node-mapnik ftbfs in unstable
tags 913708 +patch thanks This was one of the few remaining blockers for the icu transition in raspbian buster, so I hacked up a fix. I am far from an expert (just a maintainer of a Debian derivative who ran into this build failure) but here is my interpretation of what is going on. mapbox::geometry::geometry is a "variant" type which can be one of a variety of subtypes. There is an implementation of encode_geometry_pbf that takes said variant and uses some template magic to look up the type stored in the variant and dispatch it to the correct implementation. It looks like a new type "empty" was added to the list of types supported by the variant. When the template magic trys to generate the dispatch for the variant the compiler fails to find the routine to dispatch to, for reasons I don't fully understand it considers this as "ambiguous" rather than "no match". The fix was to add an implementation of encode_geometry_pbf for mapbox::geometry::empty . From reading the existing "multi point" implementation I concluded this implementation should simply return false (I am far from an expert) and implemented it as such. The wrinkle was that ideally the fix would be implemented in mapnik-vector-tile, but it seems that cannot be built on 32-bit systems (raspbian is 32-bit), building it in debian buster seems to be blocked up by some ICU symbols issue and building it in Debian sid seems to be blocked up by the hdf5 transition. The way I got around that wrinke was making the node-mapnik build process copy the headers to the build-tree, then patch them. That way I could fix the issue from the node-mapnik source package. ugly but it works. A debdiff should show up soon at https://debdiffs.raspbian.org/main/n/node-mapnik no intent to NMU in Debian.
Bug#912596: cpufrequtils: cpufreq-info only shows 31 CPUs
Package: linux Followup-For: Bug #912596 (I sent this before, but for some reasons it didn't get into bts.) I have 32 cpus. So cpus indexed 0 - 31. Yes. * the cpu 0 - 30 show correct power/frequency info. * cpu 31 doesn't. Please inspect carefully my attached outputs of the tools used. So it only works for 31 CPUs, as in the subject. Thanks! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#898202: Current state
Hello! I'm still working on this. Sorry for lack of updates! I'm a bit busy at work this week, but I would love to show what I've got so far this weekend if you have any advice to offer. Scott On 11/19/2018 11:53 AM, kaliko wrote: Hi, Any news regarding mp3gain packaging? Cheers k
Bug#914130: netfilter-persistent: initscript netfilter-persistent, action "restart" failed (/sbin/iptables-restore: not found)
Control: forcemerge 914130 911833 thanks Hello thank you for your bug report, I'm merging it into #911833 as it is the result of iptables-1.8.0-1~exp1 moving iptables binaries[*] from /sbin to /usr/sbin/ [*] not really binaries but symlinks managed by alternatives after 1.8.1-2 and other changes -- IRC: gfa GPG: 0X44BB1BA79F6C6333
Bug#914157: munin-plugins-core: smart_ constantly warning about smartctl exit status 0
Control: tags -1 + fixed-upstream Control: forwarded -1 https://github.com/munin-monitoring/munin/issues/1100 Control: fixed -1 2.0.43-1 Sorry for the noise - while writing a patch I discovered that this bug was already identified and fixed upstream and included in Debian unstable (but not stretch-backports). -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#904111: clamav-daemon causing deadlocks/blocking I/O
Ah, so I think you may have the winner. I set my temp directory to be something other than /tmp, and turned ClamAV back on, and it's been running for about an hour now with no obvious ill effects. I will report back if something else crops up, but I think this may solve it. Thank you! On Mon, Nov 19, 2018 at 2:31 PM Sebastian Andrzej Siewior wrote: > On 2018-11-19 21:01:07 [+0100], To Adam Lambert wrote: > > On 2018-11-12 10:17:32 [-0800], Adam Lambert wrote: > > > I believe I already supplied all that way back when I opened up this > bug > > > report. But for reference, here it is again: > > > > I tried it back then with no luck. Thanks for the info. I will try to > > reproduce this asap and get back to you. > > Okay. It triggers. This > > OnAccessIncludePath /tmp > > seems to be the root of all evil. Removing this option or adding > > TemporaryDirectory /var/tmp/ > > seems to make it go away. So I *think* the problem is that clamav makes > temporary files during scanning which in turn it tries to scan and > blocks itself. > Can you acknowledge the behaviour? > > Sebastian >
Bug#914159: gitlab: Problem with GPG Keys
Package: gitlab
Version: 11.1.8+dfsg-2
Severity: normal
After install 11.1.8, importing GPG keys isn't working.
This failure isn't present at 10.8 previous version on Testing.
When I try to upload my GPG key, gitlab gives a 500 internal server error.
After reloading, key are added but without reading the complete key (I think,
beucase gitlab only have detected one of the emails on the key).
Error message on production.log are:
Started POST "/profile/gpg_keys" for x.x.x.x at 2018-11-20 01:30:26 +0100
Processing by Profiles::GpgKeysController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]",
"gpg_key"=>"[FILTERED]", "commit"=>"Add key"}
Completed 500 Internal Server Error in 82ms (ActiveRecord: 1.6ms)
GPGME::Error (Unsupported protocol):
lib/gitlab/gpg.rb:15:in `fingerprints_from_key'
lib/gitlab/gpg.rb:25:in `block in fingerprints_from_key'
lib/gitlab/gpg.rb:93:in `optimistic_using_tmp_keychain'
lib/gitlab/gpg.rb:75:in `block in using_tmp_keychain'
lib/gitlab/gpg.rb:74:in `synchronize'
lib/gitlab/gpg.rb:74:in `using_tmp_keychain'
lib/gitlab/gpg.rb:24:in `fingerprints_from_key'
app/models/gpg_key.rb:111:in `extract_fingerprint'
app/services/gpg_keys/create_service.rb:4:in `execute'
app/controllers/profiles/gpg_keys_controller.rb:10:in `create'
lib/gitlab/i18n.rb:51:in `with_locale'
lib/gitlab/i18n.rb:57:in `with_user_locale'
app/controllers/application_controller.rb:362:in `set_locale'
lib/gitlab/middleware/multipart.rb:97:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only/controller.rb:38:in `call'
lib/gitlab/middleware/read_only.rb:16:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
lib/gitlab/middleware/release_env.rb:10:in `call'
Started GET "/favicon.ico" for x.x.x.x at 2018-11-20 01:30:26 +0100
Started POST "/profile/gpg_keys" for x.x.x.x at 2018-11-20 01:30:32 +0100
Processing by Profiles::GpgKeysController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]",
"gpg_key"=>"[FILTERED]", "commit"=>"Add key"}
[ActiveJob] Enqueued ActionMailer::DeliveryJob (Job ID:
10f8706f-4e6c-4218-ac69-db767782315a) to Sidekiq(mailers) with arguments:
"Notify", "new_gpg_key_email", "deliver_now", 5
Redirected to https://git.example.com/profile/gpg_keys
Completed 302 Found in 1687ms (ActiveRecord: 184.4ms)
On 10.8 version, if I add my GPG key to my profile, I can see all my emails.
Now, on 11.1, I only see one email. I've tested it with the same key always,
but now I didn't have a 10.8 debian installation for re-testing and getting
information from the logfile.
After searching for this bug on gitlab-ce official repository, I can only find
cases with 9.5 version, when gitlab didn't support subkeys. Maybe that's a
problem with the packaging.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.23--grs-ipv6-64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gitlab depends on:
ii asciidoctor1.5.7.1-1
ii bc 1.07.1-2+b1
ii bundler1.16.1-3
ii bzip2 1.0.6-9
ii dbconfig-pgsql 2.0.10
ii debconf [debconf-2.0] 1.5.69
ii exim4-daemon-light [mail-transport-agent] 4.91-8+b1
ii gitlab-common 11.1.8+dfsg-2
ii gitlab-shell 7.2.0+dfsg-1
ii gitlab-workhorse 5.2.0+debian-2
ii lsb-base 9.20170808
ii nginx 1.14.1-1
ii nginx-full [nginx] 1.14.1-1
ii nodejs 8.11.2~dfsg-1
ii npm5.8.0+ds6-2
ii openssh-client 1:7.9p1-4
ii postgresql-client 11+194
ii postgresql-client-10 [postgresql-client] 10.5-1
ii postgresql-client-11 [postgresql-client] 11.1-1+b1
ii postgresql-contrib 11+194
ii rake 12.3.1-3
ii redis-server 5:5.0.1-1
ii ruby 1:2.5.1
ii ruby-ace-rails-ap 4.1.1-1
ii ruby-acts-as-taggable-on 5.0.0-2
ii ruby-addressable 2.5.2-1
ii ruby-akismet 2.0.0-1
ii ruby-arel 6.
Bug#914157: munin-plugins-core: smart_ constantly warning about smartctl exit status 0
Package: munin-plugins-core Version: 2.0.42-5~bpo9+1 Severity: normal Dear Maintainer, A code change¹ made to munin plugin smart_ introduced a bug where smartctl exit status is triggering a warning. Before 2.0.40: # munin-run smart_sda config | grep status.warning smartctl_exit_status.warning 1 After 2.0.40: # munin-run smart_sda config | grep status.warning smartctl_exit_status.warning 1: ^ Looks like due to some refactoring, that the usual SMART critical values are specified as minimum's (e.g. "Reallocated_Sector_Ct.critical 010:"), a mistake was introduced that smartctl exit status treated the same way, when in fact it should be treated as a maximum range. ¹ https://github.com/munin-monitoring/munin/commit/7f755efb7325423d8df482be6a1234c9a14ccac3 -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (601, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 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 munin-plugins-core depends on: ii munin-common 2.0.42-5~bpo9+1 ii perl 5.24.1-3+deb9u4 Versions of packages munin-plugins-core recommends: ii libnet-snmp-perl 6.0.1-2 Versions of packages munin-plugins-core suggests: ii conntrack1:1.4.4+snapshot20161117-5 ii libcache-cache-perl 1.08-2 ii libdbd-mysql-perl4.041-2 ii libhttp-date-perl6.02-1 ii libnet-dns-perl 1.07-1 ii libnet-ip-perl 1.26-1 pn libnet-ldap-perl ii libnet-netmask-perl 1.9022-1 ii libnet-telnet-perl 3.04-1 ii libxml-parser-perl 2.44-2+b1 ii python3 3.5.3-1 ii ruby 1:2.3.3 -- no debconf information -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#914158: kpartx package includes wrong del-part-nodes.rules udev file
Package: kpartx Version: 0.7.8-2 The logic in the rules file to install del-part-nodes.rules is invalid. Instead of copying it, it copies dm-parts.rules The line [ ! -f kpartx/del-part-nodes.rules ] || cp kpartx/dm-parts.rules debian/kpartx.del-part-nodes.udev should be replaced with [ ! -f kpartx/del-part-nodes.rules ] || cp kpartx/del-part-nodes.rules debian/kpartx.del-part-nodes.udev
Bug#914059: git-remote-gcrypt: fails without mentioning that the fingerprint for the RSA key sent by the remote host has changed
Hello intrigeri and moire, On Mon 19 Nov 2018 at 01:54PM +0100, intrigeri wrote: > moire: >> I was no longer able to use an encrypted git repo after the fingerprint >> for the RSA key sent by the remote host changed, > > To be 100% clear, the key moire is referring to is the *SSH* host key. Thanks. I think the best option might simply be if git-remote-gcrypt stops hiding the output from git when this failure occurs? > I've personally suggested moire reports this with severity=important > because it's been a serious UX stumbling block. I think that it > explains a number of similar issues I've been reported in the past, > that I did not manage to explain back then. Fair enough. > And as discussed at last DebConf, from now on we at Tails will try to > more consistently report all the smallish UX papercuts that make our > git-remote-gcrypt experience more painful than it should be :) That would be great. -- Sean Whitton signature.asc Description: PGP signature
Bug#859123: automating process for publishing DLAs on the website
Hi! Many of you probably already know this website and its precious RSS feed: https://www.debian.org/security/ Few of you might already know that DLAs are *supposed* to show up in there as well, and did for a while. For example, here's a few DLAs in 2014: https://www.debian.org/security/2014/ The process broke down a while back, and reasons don't matter. We need to figure out how to fix this. So I opened #859122 to import the missing DLAs and I've made good progress. But I've opened this bug report (#859123) to fix the process. So far, the idea we had was to make LTS contributors submit a patch to the website as part of the DLA publication process. You'd run the little "parse-dla.pl" script which would create two files in the webwml git repository, separate from the security tracker! that's where the debian.org website lives.. Then you'd commit those and send a merge request to the project (or just push if you have the rights). The webmaster folks seemed to be open to grant us access to the repo to remove friction as well.. How does that sound? Another thing I thought we could do would be to hook that script into a mailbox that would receive mail from the debian-lts-announce list and automatically publish the results into git. But so far my efforts at automating things on Debian infrastructure have mostly failed, so I'm not sure it's the way to go. Besides, the parse-dsa.pl script isn't exactly solid, and don't like the idea of parsing arbitrary input like this without a human oversight. But it would certainly reduce friction to a minimum, which I like. Any other ideas? Thanks! A. -- Only in the darkness can you see the stars. - Martin Luther King, Jr.
Bug#914156: munin-plugins-extra: ipmi_sensor_ arbitrarily reverses min:max values in warnings/criticals for fans
Control: tags -1 + patch
The attached patch fixes this bug.
--
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
From 387792ac15559f15c53322f2a685c30d55a21317 Mon Sep 17 00:00:00 2001
From: Gerald Turner
Date: Mon, 19 Nov 2018 15:48:10 -0800
Subject: [PATCH] Fix Debian bug #914156: ipmi_sensor_ arbitrarily reverses
min:max values in warnings/criticals for fans
---
plugins/node.d/ipmi_sensor_.in | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/plugins/node.d/ipmi_sensor_.in b/plugins/node.d/ipmi_sensor_.in
index aebf5c72..0102d240 100644
--- a/plugins/node.d/ipmi_sensor_.in
+++ b/plugins/node.d/ipmi_sensor_.in
@@ -265,13 +265,8 @@ def config_unit(unit):
if 'unc+' in assertions:
warn_u = values['upper non-critical'].replace("na", "")
-# TODO add 'fans'
-if 'rpm' == unit:
-warn = "%s:%s" % (warn_u, warn_l)
-crit = "%s:%s" % (crit_u, crit_l)
-else:
-warn = "%s:%s" % (warn_l, warn_u)
-crit = "%s:%s" % (crit_l, crit_u)
+warn = "%s:%s" % (warn_l, warn_u)
+crit = "%s:%s" % (crit_l, crit_u)
if warn != ":":
print("%s.warning %s" % (nname, warn))
--
2.19.1
signature.asc
Description: PGP signature
Bug#859122: about 500 DLAs missing from the website
On 2017-03-30 11:22:05, Antoine Beaupre wrote: > Is there any reason why new DLAs have not been imported? > > Is there anything we can do to help in completing that import? So after further research, I can answer my own questions. It's unclear why the process has broken down, but it's clear that the current webmaster team is not in a position to do that work. For DLAs, they do not have the templates they normally use for DSA. I looked at the parse-dsa.pl script and it looks like it might just be possible to batch-import the missing advisories. I started looking into that into the following MRs: https://salsa.debian.org/webmaster-team/webwml/merge_requests/41 https://salsa.debian.org/webmaster-team/webwml/merge_requests/42 https://salsa.debian.org/webmaster-team/webwml/merge_requests/43 And will eventually batch-import everything in one monstrous merge request. Then we need to figure out workflow, which I'll do in that other bug report. A. -- Blind respect for authority is the greatest enemy of truth. - Albert Einstein
Bug#914138: munin-plugins-extra: ipmi_sensor_ python error: AttributeError: 'str' object has no attribute 'decode'
Control: tags -1 + patch
The attached patch fixes this bug.
--
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
From 3ac419bc8402b790a42555adfeab44a5e60295ad Mon Sep 17 00:00:00 2001
From: Gerald Turner
Date: Mon, 19 Nov 2018 15:44:37 -0800
Subject: [PATCH] Fix Debian bug #914138: ipmi_sensor_ python error:
AttributeError: 'str' object has no attribute 'decode'
---
plugins/node.d/ipmi_sensor_.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/plugins/node.d/ipmi_sensor_.in b/plugins/node.d/ipmi_sensor_.in
index aebf5c72..e13dcca9 100644
--- a/plugins/node.d/ipmi_sensor_.in
+++ b/plugins/node.d/ipmi_sensor_.in
@@ -221,7 +221,6 @@ UNITS_TO_SENSORS = {
if access(CONFIG, R_OK):
for line in open(CONFIG):
-line = line.decode()
if line.strip().startswith('#'):
continue
data = line.split('=', 1)
--
2.19.1
signature.asc
Description: PGP signature
Bug#914156: munin-plugins-extra: ipmi_sensor_ arbitrarily reverses min:max values in warnings/criticals for fans
Package: munin-plugins-extra Version: 2.0.42-5~bpo9+1 Severity: normal Dear Maintainer, There was an issue¹ reported to munin github which proposed a "fix" for one person's hardware, that broke on everyone elses hardware. Looking at two servers (both SuperMicro), showing ipmitool output and munin-run output with the version of ipmi_sensor_ in the 2.0.33-1 package: server1# ipmitool -I open sensor get "FAN 1" Locating sensor record... Sensor ID : FAN 1 (0x41) Entity ID : 29.1 Sensor Type (Threshold) : Fan Sensor Reading: 4800 (+/- 0) RPM Status: ok Lower Non-Recoverable : 300.000 Lower Critical: 450.000 Lower Non-Critical: 600.000 Upper Non-Critical: 18975.000 Upper Critical: 19050.000 Upper Non-Recoverable : 19125.000 Positive Hysteresis : 75.000 Negative Hysteresis : 75.000 Assertion Events : Assertions Enabled: lcr- lnr- unc+ ucr+ unr+ Deassertions Enabled : lcr- lnr- unc+ ucr+ unr+ server1# munin-run ipmi_sensor_u_rpm config | grep fan_1 fan_1.label FAN 1 fan_1.warning :18975.000 fan_1.critical 450.000:19050.000 server2# ipmitool -I open sensor get "FAN1" Locating sensor record... Sensor ID : FAN1 (0x41) Entity ID : 29.1 Sensor Type (Threshold) : Fan Sensor Reading: 800 (+/- 0) RPM Status: ok Lower Non-Recoverable : 300.000 Lower Critical: 500.000 Lower Non-Critical: 700.000 Upper Non-Critical: 25300.000 Upper Critical: 25400.000 Upper Non-Recoverable : 25500.000 Positive Hysteresis : 100.000 Negative Hysteresis : 100.000 Assertion Events : Assertions Enabled: lcr- lnr- ucr+ unr+ Deassertions Enabled : lcr- lnr- ucr+ unr+ server2# munin-run ipmi_sensor_u_rpm config | grep fan1 fan1.label FAN1 fan1.critical 500.000:25400.000 Compared to munin-run output with the version of ipmi_sensor_ in the 2.0.42-5~bpo9+1 package: server1# munin-run ipmi_sensor_u_rpm config | grep fan_1 fan_1.label FAN 1 fan_1.warning 18975.000: ^^ fan_1.critical 19050.000:450.000 ^ server2# munin-run ipmi_sensor_u_rpm config | grep fan1 fan1.label FAN1 fan1.critical 25400.000:500.000 ^ The Lower/Upper, Critical/Non-Critical values have been reversed. The following lines of code in the plugin are causing this reversal: 268: # TODO add 'fans' 269: if 'rpm' == unit: 270: warn = "%s:%s" % (warn_u, warn_l) 271: crit = "%s:%s" % (crit_u, crit_l) 272: else: 273: warn = "%s:%s" % (warn_l, warn_u) 274: crit = "%s:%s" % (crit_l, crit_u) Apologies for not commenting on the upstream github repository directly, as I do not have a github account. However another user had reported the same problem in the last comment² of the closed bug report. ¹ https://github.com/munin-monitoring/munin/issues/301 ² https://github.com/munin-monitoring/munin/issues/301#issuecomment-380997171 -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (601, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 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 munin-plugins-extra depends on: ii munin-common 2.0.42-5~bpo9+1 ii perl 5.24.1-3+deb9u4 munin-plugins-extra recommends no packages. Versions of packages munin-plugins-extra suggests: pn libcache-memcached-perl ii libnet-ip-perl 1.26-1 ii libnet-netmask-perl 1.9022-1 ii libnet-snmp-perl 6.0.1-2 ii libnet-telnet-perl 3.04-1 ii libtext-csv-xs-perl 1.26-1 ii libxml-libxml-perl 2.0128+dfsg-1+deb9u1 ii python3 3.5.3-1 -- Configuration Files: /etc/munin/plugin-conf.d/dhcpd3 [Errno 13] Permission denied: '/etc/munin/plugin-conf.d/dhcpd3' /etc/munin/plugin-conf.d/spamstats [Errno 13] Permission denied: '/etc/munin/plugin-conf.d/spamstats' -- no debconf information -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#914152: [libglib2.0-dev] Missing .gir files
On Mon, 19 Nov 2018 at 23:35:38 +0100, rastersoft wrote: > The .gir files are missing, so it is not possible to compile programs that > require GObject-2.0.gir or Gio-2.0.gir files. These are not actually maintained as part of GLib - they come from the gobject-introspection source package. As a result, they're in the libgirepository1.0-dev package. What program or toolchain are you using that requires those GIR XML files? It should probably have a dependency or build-dependency (as appropriate) on libgirepository1.0-dev. > gir1.2-glib-2.0.deb package only contains the .typelib files. FYI, all gir1.2-* packages only contain the typelib files. smcv
Bug#914089: paricfg.h, pari.cfg: wrong gzip, zcat paths when built on a merged-/usr system and run on a non-merged-/usr systemo
On Mon, 19 Nov 2018 at 14:33:42 +0100, Bill Allombert wrote: > On Mon, Nov 19, 2018 at 08:46:49AM +, Simon McVittie wrote: > > * /usr/lib/*/pari/pari.cfg and /usr/include/*/pari/paricfg.h contain > > absolute paths /usr/bin/gzip, /usr/bin/zcat > > * If pari invokes those commands (I assume it does, but I haven't actually > > checked) then it will not work on non-merged-/usr systems, where > > /bin/gzip and /bin/zcat exist, but /usr/bin/gzip and /usr/bin/zcat do not > > Is not merged system supposed to have a /usr -> / symlink ? Yes, although the symlinks are the other way round (/bin is a symlink to /usr/bin and so on). The point of recent merged-/usr efforts[1] is to group together all the static, read-only directories that need the same handling (/usr, /bin, /sbin, /lib*) into one directory, possibly a separate filesystem mounted from the initramfs or bind-mounted read-only into a container. Compiling on unmerged /usr and using on merged /usr works OK, because of the symlinks you mentioned, but that's the opposite of the situation in this bug report. The problem case is when you compile on merged-/usr and use on unmerged-/usr: - compile time, on merged /usr: which(1) etc. can't guess whether /bin/foo or /usr/bin/foo is meant to be canonical, because both exist and are equivalent - runtime, on unmerged /usr: only the canonical paths will work (/bin/gzip good, /usr/bin/gzip bad; /usr/bin/dpkg good, /bin/dpkg bad) so if the build system guessed wrong, the program doesn't work (and it can't guess right without a long list of exceptions, because some standard utilities are canonically in /usr/bin and some in /bin) > > Patching Configure, config/locate > > and/or config/paricfg.h.SH is probably easiest. > > I think the better fix would be to replace the absolute path by a > relative path (i.e.just ZCAT="gzip -dc"). That seems a valid patch for this bug, yes (assuming nothing is relying on ZCAT starting with an absolute path). smcv [1] The hurd-i386 port tried to do the opposite, making /usr a symlink to /, but that has all the same pain points as merged /usr without its advantages (because static/read-only files are still spread between /bin, /sbin, /lib* and /share, and are hard to separate from /etc which also needs to be on the root filesystem).
Bug#914155: netfilter-persistent save modprobe ERROR
Package: iptables-persistent
Version: 1.0.9
debian Buster/testing from 19. Nov. 2018
running 'netfilter-persistent save' gives funny errors including $PWD
modprobe -d requires an argument or could be omitted completely.
# netfilter-persistent save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open
moddep file '/root/-q/lib/modules/4.18.0-2-amd64/modules.dep.bin'
modprobe: FATAL: Module ip6table_filter not found in directory
/root/-q/lib/modules/4.18.0-2-amd64
#
possible fix:
--- /usr/share/netfilter-persistent/plugins.d/25-ip6tables.orig 2018-11-19
23:07:31.895973731 +0100
+++ /usr/share/netfilter-persistent/plugins.d/25-ip6tables 2018-11-19
23:07:40.991973533 +0100
@@ -34,7 +34,7 @@
{
#save IPv6 rules
#need at least ip6table_filter loaded:
- /sbin/modprobe -d -q ip6table_filter || true
+ /sbin/modprobe -d / -q ip6table_filter || true
if [ ! -f /proc/net/ip6_tables_names ]; then
log_action_cont_msg "Warning: skipping IPv6 (Kernel support is
missing)"
elif [ -x /sbin/ip6tables-save ]; then
Thanks for taking care,
Urs
Bug#913761: lintian: debian-watch-file-should-mangle-version does not recognize @DEB_EXT@
tags 913761 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/b1308b369b98985c46d050fb7604f4272abd066b checks/watch-file.pm | 11 --- debian/changelog | 4 t/tests/watch-file-should-mangle-unrel/debian/debian/watch | 4 t/tests/watch-file-should-mangle-unrel/desc| 6 ++ t/tests/watch-file-should-mangle-unrel/tags| 0 5 files changed, 22 insertions(+), 3 deletions(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914154: CVE-2018-19358
Package: gnome-keyring Version: 3.28.2-1 Severity: grave Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19358, I'm unfamiliar with the details of gnome-keyring, not sure if the severity is appropriate, just adjusted as needed. Cheers, MOritz
Bug#914153: Update to version 2.3.0-3 breaks Megaglest
Package: libftgl2 Version: 2.3.0-3 After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text rendering in Megaglest is broken. Text is shown correctly in menus, but text displayed in the game itself is replaced by white rectangles.
Bug#914124: bind9: crash on assertion dns_rdata_compare (DNSSEC validation)
Philippe, If you are able to provide more detailed information, or to identify the source of the assertion, please also notify ISC at security-offi...@isc.org. Thank you! Victoria Risk Product Manager Internet Systems Consortium vi...@isc.org
Bug#914152: [libglib2.0-dev] Missing .gir files
Package: libglib2.0-dev Version: 2.58.1-2 Severity: important --- Please enter the report below this line. --- The .gir files are missing, so it is not possible to compile programs that require GObject-2.0.gir or Gio-2.0.gir files. And, as supposed, the gir1.2-glib-2.0.deb package only contains the .typelib files. --- System information. --- Architecture: Kernel: Linux 4.18.0-2-amd64 Debian Release: buster/sid 500 unstable-debug debug.mirrors.debian.org 500 unstable ftp.debian.org 500 suldr www.bchemnet.com 500 stable repo.skype.com 500 stable packages.microsoft.com 500 stable dl.google.com --- Package information. --- Depends (Version) | Installed ===-+-= libglib2.0-0 (= 2.58.1-2) | libglib2.0-bin (= 2.58.1-2) | libglib2.0-dev-bin (= 2.58.1-2) | libpcre3-dev (>= 1:8.31) | pkg-config | zlib1g-dev | Package's Recommends field is empty. Suggests (Version) | Installed =-+-=== libglib2.0-doc | 2.58.1-2 -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com
Bug#904111: clamav-daemon causing deadlocks/blocking I/O
On 2018-11-19 21:01:07 [+0100], To Adam Lambert wrote: > On 2018-11-12 10:17:32 [-0800], Adam Lambert wrote: > > I believe I already supplied all that way back when I opened up this bug > > report. But for reference, here it is again: > > I tried it back then with no luck. Thanks for the info. I will try to > reproduce this asap and get back to you. Okay. It triggers. This OnAccessIncludePath /tmp seems to be the root of all evil. Removing this option or adding TemporaryDirectory /var/tmp/ seems to make it go away. So I *think* the problem is that clamav makes temporary files during scanning which in turn it tries to scan and blocks itself. Can you acknowledge the behaviour? Sebastian
Bug#914124: core dump backtrace
Hello everyone. Just got a backtrace from the coredump file: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0xbba66df4 in __GI_abort () at abort.c:89 #2 0xe000a8bc in assertion_failed (file=, line=, type=, cond=) at ../../../bin/named/main.c:232 #3 0xbbe7274c in isc_assertion_failed () from /usr/lib/aarch64-linux-gnu/libisc.so.160 #4 0xbc339400 in dns_rdata_compare (rdata1=, rdata2=0xb5608e70) at ../../../lib/dns/rdata.c:421 #5 0xbba67600 in msort_with_tmp (p=0xb924dcd8, b=0xb924dc18, n=3) at msort.c:124 #6 0xbba6745c in msort_with_tmp (n=2, b=0xb924dc20, p=0xb924dcd8) at msort.c:45 #7 msort_with_tmp (p=0xb924dcd8, b=0x28, n=281473787943944) at msort.c:54 #8 0xbba6745c in msort_with_tmp (n=3, b=0xb924dc18, p=0xb924dcd8) at msort.c:45 #9 msort_with_tmp (p=0xb924dcd8, b=0xa0808498, n=1) at msort.c:54 #10 0xbba67804 in msort_with_tmp (n=5, b=, p=0xb924dd28) at msort.c:45 #11 __GI___qsort_r (b=b@entry=0xb5608dd0, n=5, n@entry=13744632836034396160, s=s@entry=40, cmp=cmp@entry=0xbc2caea8 , arg=arg@entry=0x0) at msort.c:254 #12 0xbba679d0 in __GI_qsort (b=b@entry=0xb5608dd0, n=n@entry=13744632836034396160, s=s@entry=40, cmp=cmp@entry=0xbc2caea8 ) at msort.c:308 #13 0xbc2cb0f4 in rdataset_to_sortedarray (set=, mctx=0xf3852de0, rdata=0xb924dec8, nrdata=0xb4543430) at ../../../lib/dns/dnssec.c:136 #14 0xb924dbe0 in ?? () Backtrace stopped: not enough registers or memory available to unwind further This is really strange: (gdb) frame 13 #13 0xbc2cb0f4 in rdataset_to_sortedarray (set=, mctx=0xf3852de0, rdata=0xb924dec8, nrdata=0xb4543430) at ../../../lib/dns/dnssec.c:136 136 qsort(data, n, sizeof(dns_rdata_t), rdata_compare_wrapper); (gdb) print n $20 = 4 (gdb) print &data[3] $21 = (dns_rdata_t *) 0xb5608e48 Here is what: (frame 4) - rdata_compare procedure (called by libc qsort) we have rdata2 as 0xb5608e70 0xb5608e70 > 0xb5608e48 (gdb) print &data[4] $22 = (dns_rdata_t *) 0xb5608e70 This is what confusing me! How is it happening. Continue my investigation. -- Philippe Duke Network software engineer System-level developer NetAssist LLC Ukraine Khreshchatyk Street, 10B, office 8 AS29632 http://netassist.ua Our GitHub Repository: https://github.com/netassist-ua
Bug#914151: dlz-ldap-enum FTBFS with bind9 9.11.5
Source: dlz-ldap-enum Version: 1.1.0-1 Severity: serious Tags: ftbfs buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dlz-ldap-enum.html ... /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/build/1st/dlz-ldap-enum-1.1.0=. -fstack-protector-strong -Wformat -Werror=format-security -c -o dlz_ldap_enum_driver.lo dlz_ldap_enum_driver.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/build/1st/dlz-ldap-enum-1.1.0=. -fstack-protector-strong -Wformat -Werror=format-security -c dlz_ldap_enum_driver.c -fPIC -DPIC -o .libs/dlz_ldap_enum_driver.o In file included from dlz_ldap_enum_driver.c:73: sdlz_helper.h:60:2: error: unknown type name 'isc_boolean_t' isc_boolean_t direct; ^ dlz_ldap_enum_driver.c:357:19: error: unknown type name 'isc_boolean_t'; did you mean 'isc_socket_t'? void *ptr, isc_boolean_t allnodes, char *tel, ^ isc_socket_t dlz_ldap_enum_driver.c: In function 'ldap_get_results': dlz_ldap_enum_driver.c:862:12: warning: implicit declaration of function 'ldap_process_results'; did you mean 'ldap_get_results'? [-Wimplicit-function-declaration] result = ldap_process_results((LDAP *) dbi->dbconn, ldap_msg, ^~~~ ldap_get_results dlz_ldap_enum_driver.c:864:17: error: 'isc_boolean_true' undeclared (first use in this function); did you mean 'isc_buffer_free'? ptr, isc_boolean_true, NULL, ^~~~ isc_buffer_free dlz_ldap_enum_driver.c:864:17: note: each undeclared identifier is reported only once for each function it appears in dlz_ldap_enum_driver.c:871:17: error: 'isc_boolean_false' undeclared (first use in this function); did you mean 'isc_buffer_base'? ptr, isc_boolean_false, tel, ^ isc_buffer_base make[2]: *** [Makefile:489: dlz_ldap_enum_driver.lo] Error 1
Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder
Package: pcmanfm Version: 1.3.0-1 Severity: normal Tags: upstream Dear Maintainer, Opening a folder with 897 files (which has subfolders and files being updated) cause a Segmentation fault, other folders are OK. Thread 1 "pcmanfm" received signal SIGSEGV, Segmentation fault. 0x76fcd070 in fm_file_info_get_path () from /usr/lib/x86_64-linux- gnu/libfm.so.4 (gdb) bt #0 0x76fcd070 in fm_file_info_get_path () at /usr/lib/x86_64-linux- gnu/libfm.so.4 #1 0x76fcfb7b in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #2 0x76dc3b6d in g_closure_invoke () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #3 0x76dd68f3 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #4 0x76ddf882 in g_signal_emit_valist () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #5 0x76ddfecf in g_signal_emit () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #6 0x76fe14f0 in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #7 0x76ce3ae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #8 0x76ce3ed8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x76ce41d2 in g_main_loop_run () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #10 0x778de8e7 in gtk_main () at /usr/lib/x86_64-linux- gnu/libgtk-x11-2.0.so.0 #11 0x555688d6 in main (argc=, argv=) at pcmanfm.c:282 (gdb) thread apply all bt Thread 10 (Thread 0x7fffe1bdf700 (LWP 31755)): #0 0x76a14a79 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x76d2a75a in g_cond_wait_until () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #2 0x76cb6061 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x76d0cc12 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x76d0c135 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x76ae6f2a in start_thread (arg=0x7fffe1bdf700) at pthread_create.c:463 #6 0x76a19edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x72902700 (LWP 31736)): #0 0x76a297e9 in __read_chk (fd=19, buf=0x72900910, nbytes=4096, buflen=) at read_chk.c:33 #1 0x76fd25ec in fm_mime_type_from_native_file () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #2 0x76fcd62e in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #3 0x76fdc043 in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #4 0x76fe190d in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #5 0x76d0cad3 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x76d0c135 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x76ae6f2a in start_thread (arg=0x72902700) at pthread_create.c:463 #8 0x76a19edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x73127700 (LWP 31735)): #0 0x76a0f739 in __GI___poll (fds=0x5582b470, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x76ce3e46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x76ce41d2 in g_main_loop_run () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #3 0x76ed67b6 in () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x76d0c135 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x76ae6f2a in start_thread (arg=0x73127700) at pthread_create.c:463 #6 0x76a19edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x73928700 (LWP 31734)): #0 0x76a0f739 in __GI___poll (fds=0x55816c50, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x76ce3e46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x76ce3f6c in g_main_context_iteration () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #3 0x76ce3fb1 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x76d0c135 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x76ae6f2a in start_thread (arg=0x73928700) at pthread_create.c:463 #6 0x76a19edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x73b99a80 (LWP 31730)): #0 0x76fcd070 in fm_file_info_get_path () at /usr/lib/x86_64-linux- gnu/libfm.so.4 #1 0x76fcfb7b in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #2 0x76dc3b6d in g_closure_invoke () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #3 0x76dd68f3 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #4 0x76ddf882 in g_signal_emit_valist () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #5 0x76ddfecf in g_signal_emit () at /usr/lib/x86_64-linux- gnu/libgobject-2.0.so.0 #6 0x76fe14f0 in () at /usr/lib/x86_64-linux-gnu/libfm.so.4 #7 0x76ce3ae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux- gnu/libglib-2.0.so.0 #8 0x76ce3ed8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x76ce41d2 in g_main_loo
Bug#734170: ftgl: "make clean" fails
Control: tags -1 + moreinfo (Please CC me if you want me to read the reply). Hi Yann, 2014-01-04 16:05 Yann Dirson: Package: libftgl2 Version: 2.1.3~rc5-4 $ debuild clean ... debuild: fatal error at line 1346: couldn't exec fakeroot debian/rules: ... The use of "SUBDIRS" is obviously violating the way automake should be used. Adding "msvc" to SUBDIRS at it probably should is probably enough, given the lack of build targets in this dir. debian/rules was completely revamped in 2.3.0-1 and all of this legacy way to call commands do things was removed in favour of the latest minimalistic dh. I haven't observed it in my builds, when the clean target is invoked automatically by git-buildpackage. That said, I guess that the bug is still present since upstream didn't change much and the problem is with Makefile.am, as far as I understand it. What I don't know is what do you mean with SUBDIRS not being used properly, my knowledge of autotools is quite shallow. Could you please submit a patch so I can forward it upstream? Cheers. -- Manuel A. Fernandez Montecelo
Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57
On Mon, Nov 19, 2018 at 07:22:11AM -0500, Jeremy Bicha wrote: > > Given that Xul is still supported in Thunderbird, let maybe drop the > > support for > > Firefox/Iceweasel (with a NOTE telling people how to migrate their existing > > secrets) and upgrade to 0.13? > > While upgrading to 0.13 would fix one problem, it still wouldn't be > able to reach Testing since it depends on libgnome-keyring which is > being removed from Debian. See https;//bugs.debian.org/892358 And actually, it's also broken on Thunderbird; I installed it and the addon manager in Thunderbird has greyed it out with a message stating that it's incompatible with 60.3. Let's remove it from unstable and stretch? Cheers, Moritz
Bug#910874: unattended-upgrades removes packages even if
forwarded -1 https://github.com/mvo5/unattended-upgrades/pull/156
tags -1 confirmed pending
Hi Jan,
Jan Kowalsky ezt írta (időpont: 2018. okt.
12., P, 17:57):
>
> Package: unattended-upgrades
> Version: 0.93.1+nmu1
> Severity: serious
>
> Even if I have configured 'Remove-Unused-Dependencies "false";' in
> apt.conf.d/50unattended-upgrades:
>
>
> // Do automatic removal of new unused dependencies after the upgrade
> // (equivalent to apt-get autoremove)
> Unattended-Upgrade::Remove-Unused-Dependencies "false";
>
> it DOES remove packages (see below) as long as apt is configured as:
There are several issues relevant to this bug. First, this option is
misleading and this is fixed here:
https://github.com/mvo5/unattended-upgrades/commit/7f84b1b029e127595fdf3d6928ac2382b640f0ee#diff-4e9bf0f40e9f1a04bed3d01667f4d2f6
The one to be set to false is this one:
Unattended-Upgrade::Remove-New-Unused-Dependencies
Also u-u can incorrectly remove previously unused packages, too which
is being fixed here:
https://github.com/mvo5/unattended-upgrades/pull/156
I'm closing this bug with the PR because the log you attached seem to
contain removal of packages unrelated to the ones upgraded.
>
> APT::AutoRemove::RecommendsImportant "false";
>
> In my understanding this shouldn't be the case.
Yes, with setting Unattended-Upgrade::Remove-New-Unused-Dependencies
u-u should not remove packages even with the above APT setting.
Thank you for reporting the bug.
Cheers,
Balint
>
> Here is the output of unattended-upgrade:
>
> unattended-upgrade -d -v --dry-run
> Initial blacklisted packages:
> Initial whitelisted packages:
> Starting unattended upgrades script
> Allowed origins are: ['o=Debian,n=stretch,l=Debian-Security',
> 'o=Debian,n=stretch,l=Debian-Security']
> Checking: icedove ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>, origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: icedove-l10n-de ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>, origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: iceowl-extension ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>, origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: libsnmp-base ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>, origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> Checking: libsnmp30 ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> Checking: lightning ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>, origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: thunderbird ([ origin:'Debian' label:'Debian-Security' site:'security.debian.org'
> isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> Checking: thunderbird-l10n-de ([ archive:'stable' origin:'Debian' label:'Debian-Security'
> site:'security.debian.org' isTrusted:True>, archive:'stable' origin:'Debian' label:'Debian-Security'
> site:'security.debian.org' isTrusted:True>])
> pkg 'enigmail' now marked delete
> sanity check failed
> pkgs that look like they should be upgraded: libsnmp-base
> libsnmp30
> Fetched 0 B in 0s (0 B/s)
>
>
> fetch.run() result: 0
> FileSize: 1594854
> DestFile:'/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> DescURI:
> 'http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> ID:0 ErrorText: ''>
> check_conffile_prompt('/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb')
> found pkg: libsnmp-base
> No conffiles in deb
> '/var/cache/apt/archives/libsnmp-base_5.7.3+dfsg-1.7+deb9u1_all.deb'
> (There is no member named 'conffiles')
> FileSize: 2331604
> DestFile:'/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> DescURI:
> 'http://security.debian.org/pool/updates/main/n/net-snmp/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> ID:0 ErrorText: ''>
> check_conffile_prompt('/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb')
> found pkg: libsnmp30
> No conffiles in deb
> '/var/cache/apt/archives/libsnmp30_5.7.3+dfsg-1.7+deb9u1_amd64.deb'
> (There is no member named 'conffiles')
> blacklist: []
> whitelist: []
> Option --dry-run given, *not* performing real actions
> Packages that will be upgraded: libsnmp-base libsnmp30
> Writing dpkg log to
> '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log'
> found partition of size 2 (['libsnmp-base', 'libsnmp30'])
> found lea
Bug#914149: libstatgen FTBFS on !amd64: test failure
Source: libstatgen Version: 1.0.14-3 Severity: important Tags: ftbfs https://buildd.debian.org/status/package.php?p=libstatgen&suite=sid ... ./test.sh make[3]: *** [../../Makefiles/Makefile.test:53: test] Error 134 make[2]: *** [../Makefiles/Makefile.common:99: test] Error 2 make[2]: Leaving directory '/<>/bam'
Bug#914148: qr-code-generator: binary-any builds require packages only in Build-Depends-Indep
Source: qr-code-generator Version: 1.2.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=qr-code-generator&suite=sid ... debian/rules override_dh_auto_clean-indep make[1]: Entering directory '/<>' dh_auto_clean --buildsystem=pybuild --sourcedirectory=python/ dh_auto_clean: unable to load build system class 'pybuild': Can't locate Debian/Debhelper/Buildsystem/pybuild.pm in @INC (you may need to install the Debian::Debhelper::Buildsystem::pybuild module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.28.0 /usr/local/share/perl/5.28.0 /usr/lib/aarch64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/aarch64-linux-gnu/perl-base) at (eval 2) line 1. BEGIN failed--compilation aborted at (eval 2) line 1. make[1]: *** [debian/rules:28: override_dh_auto_clean-indep] Error 2 This module is in dh-python, which is only in Build-Depends-Indep.
Bug#913005: ruby-rack: CVE-2018-16471: Possible XSS vulnerability in Rack
Hi Chris, On Mon, Nov 19, 2018 at 03:17:27AM -0500, Chris Lamb wrote: > Chris Lamb wrote: > > > Security team, like ruby-i18n, I would be more than happy to prepare > > and upload a stable security upload of this package when addressing > > it in jessie LTS. > […] > > Ruby team, again, I could easily upload to sid at the same time. Let > > me know here too. > > Gentle ping on the above two queries? :) I think those will be no-dsa and can be adressed via a point release, but we first need to evaluate those further. Regards, Salvatore
Bug#914147: libkolabxml FTBFS: symbol differences
Source: libkolabxml Version: 1.1.6-3 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=libkolabxml&suite=sid ... dh_makeshlibs -a -O--buildsystem=pybuild dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libkolabxml1v5/DEBIAN/symbols doesn't match completely debian/libkolabxml1v5.symbols --- debian/libkolabxml1v5.symbols (libkolabxml1v5_1.1.6-3+b2_amd64) +++ dpkg-gensymbolsIUxgTb 2018-11-16 17:42:07.534213410 + @@ -3937,6 +3937,8 @@ (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_014TznamePropTypeEEC2EPKcS7_S7_S7_@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_014TznamePropTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_014TznamePropTypeEED2Ev@Base 1.1.0 + _ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015AltrepParamTypeEEC1EPKcS7_S7_S7_@Base 1.1.6-3+b2 + _ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015AltrepParamTypeEEC2EPKcS7_S7_S7_@Base 1.1.6-3+b2 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015AltrepParamTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015AltrepParamTypeEED2Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CommentPropTypeEEC1EPKcS7_S7_S7_@Base 1.1.0 @@ -3951,8 +3953,8 @@ (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CreatedPropTypeEEC2EPKcS7_S7_S7_@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CreatedPropTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CreatedPropTypeEED2Ev@Base 1.1.0 - (optional=templinst|arch=amd64 kfreebsd-amd64)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEEC1EPKcS7_S7_S7_@Base 1.1.6 - (optional=templinst|arch=amd64 kfreebsd-amd64)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEEC2EPKcS7_S7_S7_@Base 1.1.6 +#MISSING: 1.1.6-3+b2# (optional=templinst|arch=amd64 kfreebsd-amd64)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEEC1EPKcS7_S7_S7_@Base 1.1.6 +#MISSING: 1.1.6-3+b2# (optional=templinst|arch=amd64 kfreebsd-amd64)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEEC2EPKcS7_S7_S7_@Base 1.1.6 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015CutypeParamTypeEED2Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree27element_factory_initializerILm0EcN13icalendar_2_015DtstampPropTypeEEC1EPKcS7_S7_S7_@Base 1.1.0 @@ -4395,8 +4397,8 @@ (optional=templinst|arch=!amd64 !hppa !kfreebsd-amd64)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UidPropTypeEEC2EPKcS7_S7_S7_@Base 1.1.6 (optional=templinst)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UidPropTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UidPropTypeEED2Ev@Base 1.1.0 - (optional=templinst|arch=!alpha !armel !armhf !hppa !mips64el !ppc64el !sparc64)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEEC1EPKcS7_S7_S7_@Base 1.1.0 - (optional=templinst|arch=!alpha !armel !armhf !hppa !mips64el !ppc64el !sparc64)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEEC2EPKcS7_S7_S7_@Base 1.1.0 +#MISSING: 1.1.6-3+b2# (optional=templinst|arch=!alpha !armel !armhf !hppa !mips64el !ppc64el !sparc64)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEEC1EPKcS7_S7_S7_@Base 1.1.0 +#MISSING: 1.1.6-3+b2# (optional=templinst|arch=!alpha !armel !armhf !hppa !mips64el !ppc64el !sparc64)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEEC2EPKcS7_S7_S7_@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEED1Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_011UrlPropTypeEED2Ev@Base 1.1.0 (optional=templinst)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_012DirParamTypeEED1Ev@Base 1.1.0 @@ -4407,40 +4409,40 @@ (optional=templinst|arch=!arm64 !m68k !powerpc !powerpcspe !ppc64 !s390x !sh4)_ZN3xsd3cxx4tree30element_serializer_initializerILm0EcN13icalendar_2_01
Bug#914145: liborigin2 FTBFS with boost 1.67
Source: liborigin2 Version: 2:20110117-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=liborigin2&suite=sid ... In file included from Origin800Parser.h:32, from Origin610Parser.h:32, from Origin600Parser.h:32, from Origin600Parser.cpp:29: Origin750Parser.h: In member function 'boost::posix_time::ptime Origin750Parser::doubleToPosixTime(double)': Origin750Parser.h:74:175: error: no matching function for call to 'boost::posix_time::seconds::seconds(double)' return boost::posix_time::ptime(boost::gregorian::date(boost::gregorian::gregorian_calendar::from_julian_day_number(jdt+1)), boost::posix_time::seconds((jdt-(int)jdt)*86400)); ^ In file included from /usr/include/boost/date_time/posix_time/posix_time_types.hpp:16, from /usr/include/boost/date_time/posix_time/time_formatters.hpp:16, from /usr/include/boost/date_time/posix_time/posix_time.hpp:24, from Origin750Parser.h:36, from Origin800Parser.h:32, from Origin610Parser.h:32, from Origin600Parser.h:32, from Origin600Parser.cpp:29: /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note: candidate: 'template boost::posix_time::seconds::seconds(const T&, typename boost::enable_if >::type*)' explicit seconds(T const& s, ^~~ /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note: template argument deduction/substitution failed: /usr/include/boost/date_time/posix_time/posix_time_duration.hpp: In substitution of 'template boost::posix_time::seconds::seconds(const T&, typename boost::enable_if >::type*) [with T = double]': Origin750Parser.h:74:175: required from here /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: error: no type named 'type' in 'struct boost::enable_if, void>' /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: candidate: 'boost::posix_time::seconds::seconds(const boost::posix_time::seconds&)' class BOOST_SYMBOL_VISIBLE seconds : public time_duration ^~~ /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: no known conversion for argument 1 from 'double' to 'const boost::posix_time::seconds&' /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: candidate: 'boost::posix_time::seconds::seconds(boost::posix_time::seconds&&)' /usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: no known conversion for argument 1 from 'double' to 'boost::posix_time::seconds&&'
Bug#913605: lintian: inform about lack of systemd service hardening/security options
tags 913605 + pending thanks Implemented in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/6bbed91d8afc5cc6a8f75a3b340e84abf7e960c4 checks/systemd.desc | 16 checks/systemd.pm | 11 +++ data/systemd/hardening-flags | 16 debian/changelog | 3 +++ t/tests/systemd-missing-services/desc | 1 + t/tests/systemd-missing-services/tags | 1 + 6 files changed, 48 insertions(+) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#914146: dogecoin FTBFS with boost 1.67
Source: dogecoin Version: 1.10.0-5 Severity: serious Tags: ftbfs buster sid https://buildd.debian.org/status/package.php?p=dogecoin&suite=sid ... g++ -DHAVE_CONFIG_H -I. -I../src/config -I. -I./obj -pthread -I/usr/include -I./leveldb/include -I./leveldb/helpers/memenv -I./secp256k1/include -Wdate-time -D_FORTIFY_SOURCE=2 -DBOOST_SPIRIT_THREADSAFE -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wstack-protector -fstack-protector-all -fPIC -c -o libbitcoin_server_a-rpcserver.o `test -f 'rpcserver.cpp' || echo './'`rpcserver.cpp rpcserver.cpp:507:102: error: wrong number of template arguments (2, should be 1) static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ In file included from /usr/include/boost/asio.hpp:30, from rpcprotocol.h:15, from rpcserver.h:10, from rpcserver.cpp:6: /usr/include/boost/asio/basic_socket_acceptor.hpp:73:7: note: provided for 'template class boost::asio::basic_socket_acceptor' class basic_socket_acceptor ^ rpcserver.cpp:507:104: error: template argument 1 is invalid static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ rpcserver.cpp:517:95: error: wrong number of template arguments (2, should be 1) static void RPCListen(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ In file included from /usr/include/boost/asio.hpp:30, from rpcprotocol.h:15, from rpcserver.h:10, from rpcserver.cpp:6: /usr/include/boost/asio/basic_socket_acceptor.hpp:73:7: note: provided for 'template class boost::asio::basic_socket_acceptor' class basic_socket_acceptor ^ rpcserver.cpp:517:97: error: template argument 1 is invalid static void RPCListen(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ rpcserver.cpp: In function 'void RPCListen(int, boost::asio::ssl::context&, bool)': rpcserver.cpp:522:109: error: base operand of '->' is not a pointer boost::shared_ptr< AcceptedConnectionImpl > conn(new AcceptedConnectionImpl(acceptor->get_io_service(), context, fUseSSL)); ^~ rpcserver.cpp:524:13: error: base operand of '->' is not a pointer acceptor->async_accept( ^~ rpcserver.cpp: At global scope: rpcserver.cpp:540:102: error: wrong number of template arguments (2, should be 1) static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ In file included from /usr/include/boost/asio.hpp:30, from rpcprotocol.h:15, from rpcserver.h:10, from rpcserver.cpp:6: /usr/include/boost/asio/basic_socket_acceptor.hpp:73:7: note: provided for 'template class boost::asio::basic_socket_acceptor' class basic_socket_acceptor ^ rpcserver.cpp:540:104: error: template argument 1 is invalid static void RPCAcceptHandler(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ rpcserver.cpp: In function 'void RPCAcceptHandler(int, boost::asio::ssl::context&, bool, boost::shared_ptr, const boost::system::error_code&)': rpcserver.cpp:547:67: error: base operand of '->' is not a pointer if (error != boost::asio::error::operation_aborted && acceptor->is_open()) ^~ rpcserver.cpp:548:45: error: no matching function for call to 'RPCListen(int&, boost::asio::ssl::context&, const bool&)' RPCListen(acceptor, context, fUseSSL); ^ rpcserver.cpp:517:13: note: candidate: 'template void RPCListen(int, boost::asio::ssl::context&, bool)' static void RPCListen(boost::shared_ptr< basic_socket_acceptor > acceptor, ^ rpcserver.cpp:517:13: note: template argument deduction/substitution failed: rpcserver.cpp:548:45: note: couldn't deduce template parameter 'Protocol' RPCListen(acceptor, context, fUseSSL); ^ rpcserver.cpp: In function 'void StartRPCThreads()': rpcserver.cpp:634:77: error: no matching function for call to 'boost::asio::ssl::context::c
Bug#914144: odil FTBFS with boost 1.67
Source: odil Version: 0.9.2-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=odil&suite=sid ... debian/rules override_dh_install-arch make[1]: Entering directory '/<>' dh_install dh_install: Cannot find (any matches for) "usr/lib/python2*/dist-packages/odil/*so" (tried in ., debian/tmp) dh_install: python-odil missing files: usr/lib/python2*/dist-packages/odil/*so dh_install: Cannot find (any matches for) "usr/lib/python2*/dist-packages/odil/*py" (tried in ., debian/tmp) dh_install: python-odil missing files: usr/lib/python2*/dist-packages/odil/*py dh_install: Cannot find (any matches for) "usr/lib/python3*/dist-packages/odil/*so" (tried in ., debian/tmp) dh_install: python3-odil missing files: usr/lib/python3*/dist-packages/odil/*so dh_install: Cannot find (any matches for) "usr/lib/python3*/dist-packages/odil/*py" (tried in ., debian/tmp) dh_install: python3-odil missing files: usr/lib/python3*/dist-packages/odil/*py dh_install: missing files, aborting make[1]: *** [debian/rules:107: override_dh_install-arch] Error 25 The Ubuntu diff seems to contain a fix.
Bug#914143: soundscaperenderer FTBFS on armel/armhf
Source: soundscaperenderer Version: 0.5.0~dfsg-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=soundscaperenderer&suite=sid ... checking for QT... yes checking GL/glu.h usability... no checking GL/glu.h presence... no checking for GL/glu.h... no checking OpenGL/glu.h usability... no checking OpenGL/glu.h presence... no checking for OpenGL/glu.h... no checking for library containing gluNewQuadric... no checking for library containing glSelectBuffer... no configure: error: --enable-gui (graphical user interface (using Qt)) requested but not available! make: *** [/usr/share/cdbs/1/class/autotools.mk:46: debian/stamp-autotools/qt] Error 1 The root cause is that on armel/armhf Qt5 is compiled with OpenGL ES instead of OpenGL. Ideally it should be fixed to build and work with OpenGL ES, but if this is not easily possible only soundscaperenderer-nox should be built for armel and armhf.
Bug#913667: c-blosc breaks python-blosc autopkgtest: times out
Control: forwarded -1 https://github.com/Blosc/c-blosc/issues/246 I've packaged the new release (1.6.2) and compiled with the latest blosc in the archive (1.14.4), but the problem remained. DS -- 4096R/DF5182C8 (sten...@debian.org) http://www.danielstender.com/
Bug#914142: python-visual FTBFS with boost 1.67
Source: python-visual Version: 1:5.12-1.6 Severity: serious Tags: ftbfs buster sid https://buildd.debian.org/status/package.php?p=python-visual&suite=sid ... In file included from /<>/./include/util/extent.hpp:9, from /<>/./src/core/util/extent.cpp:6: /<>/./include/util/vector.hpp:10:10: fatal error: boost/python/numeric.hpp: No such file or directory #include ^~ compilation terminated. make[2]: *** [Makefile:226: extent.lo] Error 1
Bug#914141: python-escript FTBFS with boost 1.67
Source: python-escript Version: 5.2-2 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=python-escript&suite=sid ... Install file: "debian/tmp2/posix/weipa/py/__init__.pyc" as "debian/stage2/esys/weipa/__init__.pyc" /<>/debian/stage2/bin/run-escript /<>/debian/tmp2/scripts/release_sanity.py Traceback (most recent call last): File "/<>/debian/tmp2/scripts/release_sanity.py", line 8, in from esys.escript import * File "escript/py_src/__init__.py", line 28, in from esys.escriptcore.escriptcpp import * ImportError: /<>/debian/stage2/lib/libescript.so: undefined symbol: _ZTVN5boost6python17error_already_setE scons: *** [dummy] Error 1 scons: building terminated because of errors. *** Config Summary (see config.log and /lib/buildvars for details) *** Escript revision 6702 Install prefix: /<>/debian/stage2 Python: /usr/bin/python2 (Version 2.7.15) boost: /usr (Version 1.67.0) numpy: YES (with headers) Solver library: paso Direct solver: NONE domains: dudley, finley, ripley, speckley netcdf: YES (4 + 3) weipa: YES openmp: YES gdal: YES pyproj: YES scipy: YES silo: YES DISABLED features: boomeramg cppunit cuda debug gmsh gzip lapack mkl mpi papi parmetis sympy trilinos umfpack visit Treating warnings as errors WARNING: Cannot import sympy. Symbolic toolbox and nonlinear PDEs will not be available. WARNING: matplotlib not found, will skip some unit tests WARNING: gmsh not available. Skipping tests usersguide/trapezoid.py usersguide/quad.py usersguide/brick.py usersguide/refine.py cookbook/example04a.py cookbook/example04b.py cookbook/example05a.py cookbook/example05b.py cookbook/example05c.py cookbook/example06.py cookbook/example08c.py cookbook/example09m.py cookbook/example09a.py cookbook/example10m.py inversion/dc_forward.py! ERROR: build stopped due to errors make[1]: *** [debian/rules:61: override_dh_auto_build] Error 2 The Ubuntu diff seems to contain a fix.
Bug#914140: pytango FTBFS with boost 1.67
Source: pytango
Version: 9.2.4-2
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/package.php?p=pytango&suite=sid
...
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-A8UpPM/python2.7-2.7.15=.
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
build/temp.linux-amd64-2.7/<>/ext/api_util.o
build/temp.linux-amd64-2.7/<>/ext/archive_event_info.o
build/temp.linux-amd64-2.7/<>/ext/attr_conf_event_data.o
build/temp.linux-amd64-2.7/<>/ext/attribute_alarm_info.o
build/temp.linux-amd64-2.7/<>/ext/attribute_dimension.o
build/temp.linux-amd64-2.7/<>/ext/attribute_event_info.o
build/temp.linux-amd64-2.7/<>/ext/attribute_info.o
build/temp.linux-amd64-2.7/<>/ext/attribute_info_ex.o
build/temp.linux-amd64-2.7/<>/ext/attribute_proxy.o
build/temp.linux-amd64-2.7/<>/ext/base_types.o
build/temp.linux-amd64-2.7/<>/ext/callback.o
build/temp.linux-amd64-2.7/<>/ext/change_event_info.o
build/temp.linux-amd64-2.7/<>/ext/command_info.o
build/temp.linux-amd64-2.7/<>/ext/connection.o
build/temp.linux-amd64-2.7/<>/ext/constants.o
build/temp.linux-amd64-2.7/<>/ext/data_ready_event_data.o
build/temp.linux-amd64-2.7/<>/ext/database.o
build/temp.linux-amd64-2.7/<>/ext/db.o
build/temp.linux-amd64-2.7/<>/ext/dev_command_info.o
build/temp.linux-amd64-2.7/<>/ext/dev_error.o
build/temp.linux-amd64-2.7/<>/ext/device_attribute.o
build/temp.linux-amd64-2.7/<>/ext/device_attribute_config.o
build/temp.linux-amd64-2.7/<>/ext/device_attribute_history.o
build/temp.linux-amd64-2.7/<>/ext/device_data.o
build/temp.linux-amd64-2.7/<>/ext/device_data_history.o
build/temp.linux-amd64-2.7/<>/ext/device_info.o
build/temp.linux-amd64-2.7/<>/ext/device_pipe.o
build/temp.linux-amd64-2.7/<>/ext/device_proxy.o
build/temp.linux-amd64-2.7/<>/ext/devintr_change_event_data.o
build/temp.linux-amd64-2.7/<>/ext/enums.o
build/temp.linux-amd64-2.7/<>/ext/event_data.o
build/temp.linux-amd64-2.7/<>/ext/exception.o
build/temp.linux-amd64-2.7/<>/ext/from_py.o
build/temp.linux-amd64-2.7/<>/ext/group.o
build/temp.linux-amd64-2.7/<>/ext/group_reply.o
build/temp.linux-amd64-2.7/<>/ext/group_reply_list.o
build/temp.linux-amd64-2.7/<>/ext/locker_info.o
build/temp.linux-amd64-2.7/<>/ext/locking_thread.o
build/temp.linux-amd64-2.7/<>/ext/periodic_event_info.o
build/temp.linux-amd64-2.7/<>/ext/pipe_event_data.o
build/temp.linux-amd64-2.7/<>/ext/pipe_info.o
build/temp.linux-amd64-2.7/<>/ext/poll_device.o
build/temp.linux-amd64-2.7/<>/ext/precompiled_header.o
build/temp.linux-amd64-2.7/<>/ext/pytango.o
build/temp.linux-amd64-2.7/<>/ext/pytgutils.o
build/temp.linux-amd64-2.7/<>/ext/pyutils.o
build/temp.linux-amd64-2.7/<>/ext/time_val.o
build/temp.linux-amd64-2.7/<>/ext/to_py.o
build/temp.linux-amd64-2.7/<>/ext/version.o
build/temp.linux-amd64-2.7/<>/ext/server/attr.o
build/temp.linux-amd64-2.7/<>/ext/server/attribute.o
build/temp.linux-amd64-2.7/<>/ext/server/auto_monitor.o
build/temp.linux-amd64-2.7/<>/ext/server/command.o
build/temp.linux-amd64-2.7/<>/ext/server/device_class.o
build/temp.linux-amd64-2.7/<>/ext/server/device_impl.o
build/temp.linux-amd64-2.7/<>/ext/server/dserver.o
build/temp.linux-amd64-2.7/<>/ext/server/encoded_attribute.o
build/temp.linux-amd64-2.7/<>/ext/server/fwdAttr.o
build/temp.linux-amd64-2.7/<>/ext/server/log4tango.o
build/temp.linux-amd64-2.7/<>/ext/server/multi_attribute.o
build/temp.linux-amd64-2.7/<>/ext/server/multi_class_attribute.o
build/temp.linux-amd64-2.7/<>/ext/server/pipe.o
build/temp.linux-amd64-2.7/<>/ext/server/subdev.o
build/temp.linux-amd64-2.7/<>/ext/server/tango_util.o
build/temp.linux-amd64-2.7/<>/ext/server/user_default_attr_prop.o
build/temp.linux-amd64-2.7/<>/ext/server/user_default_pipe_prop.o
build/temp.linux-amd64-2.7/<>/ext/server/wattribute.o
-l:libtango.so.9 -lboost_python-py27 -ltango -lomniDynamic4 -lCOS4 -lomniORB4
-lomnithread -llog4tango -lzmq -o
/<>/.pybuild/cpython2_2.7_tango/build/tango/_tango.so
/usr/bin/ld: cannot find -lboost_python-py27
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1
E: pybuild pybuild:338: build: plugin distutils failed with: exit code=1:
/usr/bin/python setup.py build
dh_auto_build: pybuild --build -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:7: binary-arch] Error 25
The Ubuntu diff seems to contain a fix.
Bug#911627: python-openflow: diff for NMU version 2017.2b1+dfsg-2.1
Control: tags 911627 + patch Control: tags 911627 + pending Dear maintainer, I've prepared an NMU for python-openflow (versioned as 2017.2b1+dfsg-2.1) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed diff -Nru python-openflow-2017.2b1+dfsg/debian/changelog python-openflow-2017.2b1+dfsg/debian/changelog --- python-openflow-2017.2b1+dfsg/debian/changelog 2017-11-13 19:03:47.0 +0200 +++ python-openflow-2017.2b1+dfsg/debian/changelog 2018-11-19 23:29:35.0 +0200 @@ -1,3 +1,11 @@ +python-openflow (2017.2b1+dfsg-2.1) unstable; urgency=high + + * Non-maintainer upload. + * Upstream requires Python 3.6, correct the dependencies +accordingly to fix upgrades from stretch. (Closes: #911627) + + -- Adrian Bunk Mon, 19 Nov 2018 23:29:35 +0200 + python-openflow (2017.2b1+dfsg-2) unstable; urgency=medium * New upload because the bug #877191 was solved. diff -Nru python-openflow-2017.2b1+dfsg/debian/control python-openflow-2017.2b1+dfsg/debian/control --- python-openflow-2017.2b1+dfsg/debian/control 2017-11-13 19:03:47.0 +0200 +++ python-openflow-2017.2b1+dfsg/debian/control 2018-11-19 23:29:28.0 +0200 @@ -4,10 +4,9 @@ Maintainer: Paulo Henrique de Lima Santana (phls) Build-Depends: debhelper (>= 10), dh-python, - python3.6, - python3-all, + python3-all (>= 3.6), python3-setuptools -X-Python3-Version: >= 3.5 +X-Python3-Version: >= 3.6 Standards-Version: 4.1.1 Homepage: https://github.com/kytos/python-openflow
Bug#914135: distribution-and-changes-mismatch not emitted when it should be
tags 914135 + moreinfo thanks Hi Rebecca, > > libnfs (2.0.0-1~exp1) experimental; urgency=medium [..] > > Is this something that may be notified by lintian?> > In theory, > https://lintian.debian.org/tags/distribution-and-changes-mismatch.html , > but since it didn't trigger on libnfs, it would appear to be broken. ^^^ I do note that there was a mismatch for this specific upload, ie: https://tracker.debian.org/news/946971/accepted-libnfs-200-1exp1-source-amd64-into-unstable-unstable/ … but what is the evidence for Lintian not seeing this? The maintainer could have uploaded anyway and/or they had an old version of Lintian, etc. If you are wondering why it does not appear on: https://lintian.debian.org/tags/distribution-and-changes-mismatch.html ... that is because that requires the .changes file to be around, whilst lintian.debian.org processes source packages (ie. that particular webpage is pretty useless). Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#913930: Confirmed for sbuild only
tags 913930 - moreinfo + confirmed found 913930 lintian/2.5.112 thanks Hi, I can reproduce the issue only when using sbuild. I am looking into the possibility that a dependency is missing inside sbuild. Meanwhile, I marked the bug as confirmed. Thank you!
Bug#914133: perl: Storable probes for user limits at build time, leading to reproducibility issues
clone 914133 -1 reassign -1 jenkins.debian.org retitle -1 jenkins.debian.org: Please add reproducibility variations for user limits severity -1 wishlist owner -1 Niko Tyni thanks Niko Tyni wrote: > (User limits such as this might be an idea for variations on > tests.reproducible-builds.org variations if they aren't varied already? > I don't see them currently on > https://tests.reproducible-builds.org/debian/index_variations.html FWIW.) Good idea. Cloning as a wishlist bug at the very least... Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#911793: [Debian-med-packaging] Bug#911793: autopkgtest regression: Segmentation fault
Dear Paul, On 19/11/2018 19:32, Paul Gevers wrote: It seems camitk-4.1.2-2 is not very lucky! So you are caught in the hdf5 transition: https://release.debian.org/transitions/html/auto-hdf5.html Yes, you are right. The current deadline for camitk package removal is 22 November. What do you think is the best course of action? If you comment on the RC bug that is triggering the autoremoval, then the timer gets reset. Just explain there why it can't be fixed NOW. I still agree with Mattia: "This is the signature of an ABI break not correctly handled." so I believe that should be fixed first. The RC bug that triggered the autoremoval is #909120 [1] and (I hope it) should be fixed by camitk version 4.1.2-2 (now in unstable and struggling to get into testing). The bug was closed automatically by the upload ot 4.1.2-2. Just to make sure that I understand correctly about the autoremoval: if I comment on #909120 it should delay the autoremoval? I understand as well that it might not be the best thing to do first (I just like to understand a bit better). About the ABI break: I am sorry to say that I don't really understand how to fix this. Is it possible that this ABI breaks comes from the fact camitk 4.1.2-1 is based on vtk6 (which introduced #909120 in the first place when gdcm >= 2.8.7-2 moved from python2 to python3 and consequently from vtk6 to vtk7) while camitk-4.1.2-2 is based on vtk7 and gdcm >= 2.8.7-2? If yes, should I add a "Breaks: vtk6" in d/control of camitk?And/or as you suggested earlier should I add "gdcm >= 2.8.8"? Or it is something (like "Breaks:vtk6") that should be done in gdcm or vtk7 instead? Thank you again for your message... and for your patience (and do not hesitate to refer me to some documentation or example, my packager training is far from being finished, as you can see!) Best regards, Emmanuel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909120
Bug#914138: munin-plugins-extra: ipmi_sensor_ python error: AttributeError: 'str' object has no attribute 'decode'
Package: munin-plugins-extra Version: 2.0.42-5~bpo9+1 Severity: normal Dear Maintainer, I'm no Python expert, but it appears that a code change¹ made to munin plugin ipmi_sensor_ is broken on systems with Python 3.5.3. # munin-run ipmi_sensor_u_rpm Traceback (most recent call last): File "/etc/munin/plugins/ipmi_sensor_u_rpm", line 224, in line = line.decode() AttributeError: 'str' object has no attribute 'decode' The code in question is: 75: CONFIG = '/etc/munin/ipmi' … 222: if access(CONFIG, R_OK): 223:for line in open(CONFIG): 224:line = line.decode() The built-in open()² function is reading the file in text-mode with platform default encoding, and the 'line' variable is a 'str' object, not a 'bytes' object that needs to be decoded. Perhaps some variant of Python 3 has a decode method on str objects, or open() returns bytes objects by default? Otherwise my guess is nobody ever executed this plugin since the 2.0.38 release. ¹ https://github.com/munin-monitoring/munin/commit/8637ee5244c20f4432dea5fa15ad234f98b23d1d ² https://docs.python.org/3.5/library/functions.html#open -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (601, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/8 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 munin-plugins-extra depends on: ii munin-common 2.0.42-5~bpo9+1 ii perl 5.24.1-3+deb9u4 munin-plugins-extra recommends no packages. Versions of packages munin-plugins-extra suggests: pn libcache-memcached-perl ii libnet-ip-perl 1.26-1 ii libnet-netmask-perl 1.9022-1 ii libnet-snmp-perl 6.0.1-2 ii libnet-telnet-perl 3.04-1 ii libtext-csv-xs-perl 1.26-1 ii libxml-libxml-perl 2.0128+dfsg-1+deb9u1 ii python3 3.5.3-1 -- Configuration Files: /etc/munin/plugin-conf.d/dhcpd3 [Errno 13] Permission denied: '/etc/munin/plugin-conf.d/dhcpd3' /etc/munin/plugin-conf.d/spamstats [Errno 13] Permission denied: '/etc/munin/plugin-conf.d/spamstats' -- no debconf information -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#913845: closed by Abhijith PA (Bug#913845: fixed in httping 2.5-4)
Control: reopen -1 On Sat, Nov 17, 2018 at 12:09:08PM +, Debian Bug Tracking System wrote: >[Helmut Grohne] >* Fix FTCBFS: Export a cross compiler for ./configure and make. > (Closes: #913845) You applied the patch partially. Without including buildtools.mk, CC simply becomes "cc" and that's wrong. If you dislike buildtools.mk, you can use the following: include /usr/share/dpkg/architecture.mk ifeq ($(origin CC),default) CC = $(DEB_HOST_GNU_TYPE)-gcc endif Helmut
Bug#911154: Bug#912120: Bug#911154: netkit-ntalk misses the generator for configure
On Mon, Nov 05, 2018 at 08:01:21AM +0100, Christoph Biedl wrote: >... > Switching to e.g. cmake means a one-time more-or-less complex manual > transition but afterwards the packaging should be in a sane state for > quite some time. > > After thinking about this for a few days I agree this is the sanest way > to go. For the current build system, there are already some extra > kludges (check out debian/rules if you really want to), and setting up a > confgen emulation, probably as a debhelper extension ... while this was > a faszinating project, it would certainly eat up some ressources to set > up and to maintain. Also, since confgen upstream (see below) described > the program as a hack and I subscribe to that point of view, it's > really better to look forward, even for these old packages. > > Still I assume this will be my job - however, the changes will go > beyond a sound NMU size. So I'll send out patches, and eventually go > the package salvaging way. >... Any update on that? I might provide fixes for some packages otherwise, but these would be autotools conversions since that's the tools I know best. > Cheers, > Christoph >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#914137: elpa-magit: magit-status doesn't honor path auto-completion anymore
Package: elpa-magit Version: 2.90.1-1 Severity: normal Dear Maintainer, since this last update, magit-status launched on a non-git directory asks for a path but it doesn't allow to auto-complete any. This is a regression, given it was perfectly working on previous version. Ah, I'm running helm as completion aid. Thanks. -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-magit depends on: ii elpa-dash 2.14.1+dfsg-1 ii elpa-ghub 3.0.0-3 ii elpa-git-commit 2.90.1-1 ii elpa-magit-popup 2.12.4-1 ii elpa-with-editor 2.8.0-1 ii emacsen-common3.0.4 ii git 1:2.19.1-1 elpa-magit recommends no packages. elpa-magit suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#913909: [Ceph-maintainers] Bug#913909: Bug#913909: ceph: FTBFS on i386 and mipsel (regression)
Hi Salvatore Bonaccorso writes: Hi Gaudenz, and hi James, On Mon, Nov 19, 2018 at 03:48:14PM +0100, Gaudenz Steinlin wrote: James Page writes: > https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/ceph/tree/debian/patches?h=ubuntu/xenial > I think I hit the same issue in Ubuntu a while back for which > I picked 3 rocksdb patches - see above URL - 000*.patch. Thanks James. It looks like these patches actually fix the build issue. I already had these patches applied to the build in unstable, but I did not make the connection to the infinite loop. Salvatore, do you agree to an upload of 10.2.11-2 with these patches to stretch-security? Or how should we proceed? Yes we should release a regression update for ceph via stretch-security. Can you ping us when you have it ready? I'm currently building a new fixed version (10.2.11-2). Should I just upload to stretch-security or do you want to have a look at it first? I attached the debdiff to the previous stretch-security upload. Gaudenz ceph_10.2.11-1to2.debdiff Description: Binary data > > Regards, > Salvatore > -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#849513: d/control: Conflicts can be removed
While the binary name is a long story, I believe it does not make sense to continue keeping: $ cat d/control ... Conflicts: ninja Thanks for maintaining ninja !
Bug#914136: linux: enable CONFIG_CRYPTO_MORUS* and CONFIG_CRYPTO_AEGIS*
Source: linux Version: 4.18.10-2+b1 Severity: wishlist Hi. Could you please enable the crypto modules for MORUS and AEGIS AEAD ciphers? It shoul be supported now in cryptsetup/dm-crypt for volumes with integrity protection and I'd like to play with them. Thanks, Chris. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#910990: openttd FTCBFS: uses the build architecture pkg-config
Hi Helmut, On Sun, Nov 18, 2018 at 04:27:29PM +0100, Helmut Grohne wrote: > Hi Matthijs, > > On Sat, Nov 17, 2018 at 09:28:54PM +0100, Matthijs Kooijman wrote: > > Thanks for testing and provide a patch. I've included in the build, and > > verified it works. I did run into a problem running on a system where > > buildtools.mk did not exist, due to the % wildcard rule (see > > https://lists.debian.org/debian-mentors/2011/10/msg00308.html and > > https://salsa.debian.org/openttd-team/openttd/commit/2a60f8c976c12f3338655ba4c5130213987dde9a > > ) > > Dang. I didn't think of how make would handle absence. Me neither, but at least the error message was Googlable :-) > So buildtools.mk will always exist in buster and later releases. You > only get problems when backporting to stretch or older (and we don't > care about cross compilation there). The -include was meant to make it > backport-friendly, but it ultimately failed doing exactly that. I noticed it because git-buildpackage first cleans my git checkout to generate a source package for pbuilder, which I do on a stable system. > How about adding an empty rule for /usr/share/dpkg/buildtools.mk? Would > that work for you? That would work, but I opted for replacing the wildcard rule with an explicit list. See the links I noted: https://lists.debian.org/debian-mentors/2011/10/msg00308.html https://salsa.debian.org/openttd-team/openttd/commit/2a60f8c976c12f3338655ba4c5130213987dde9a So I think I'm good, I just wanted to give you a heads up for possible future patches :-) Gr. Matthijs signature.asc Description: PGP signature
Bug#914086: /usr/lib/*/wx/config/*: potentially broken if built on a merged-/usr system and run on a non-merged-/usr system
On Mon, Nov 19, 2018 at 02:56:18PM -0500, Scott Talbert wrote: > On Mon, 19 Nov 2018, Olly Betts wrote: > > On Mon, Nov 19, 2018 at 08:32:28AM +, Simon McVittie wrote: > > > This bug can probably be fixed by passing EGREP="/bin/grep -E" as an > > > additional command-line argument when invoking configure. > > > > That was my thought too. > > > > It would be nicer to address upstream, but I don't really see a way to > > do that cleanly short of rewriting it to just use shell built-ins, which > > seems like a lot of work as it's a hairy beast. > > Or we could just patch wx-config to set EGREP to "grep -E" (without the > path)? > > https://salsa.debian.org/freewx-team/wx/blob/wx3.0-debian/wx-config.in#L92 If you mean as an upstream patch, then you need to worry about systems where a suitable grep isn't on PATH (or where the PATH set when configure was run isn't the same as the PATH set when wx-config gets run). If you mean as a debian-specific patch, that means we get to carry a patch indefinitely. If it can be cleanly addressed by passing an extra option to configure that seems better to me. We can rely on "/bin/grep" continuing to work, it's just that "/usr/bin/grep" only works when /usr == / (and presumably whichever autoconf macro it is searches PATH and /usr/bin is before /bin on the default PATH so it finds /usr/bin/grep first). Cheers, Olly
Bug#914086: /usr/lib/*/wx/config/*: potentially broken if built on a merged-/usr system and run on a non-merged-/usr system
On Mon, 19 Nov 2018, Olly Betts wrote: On Mon, Nov 19, 2018 at 08:32:28AM +, Simon McVittie wrote: Recent tests on tests.reproducible-builds.org use unmerged /usr for the first build and merged /usr for the second, as a way to detect some issues in this class. Thanks for the report. $EGREP is used by the script, and changing it to point to a path that doesn't exists leads to wx-config failing with an error such as: Warning: No config found to match: /usr/bin/wx-config --cppflags in /usr/lib/x86_64-linux-gnu/wx/config I'd actually spotted this (also via reproducible-builds) yesterday but only after I made the recent upload. Unless any of the current buildds has a merged /usr I suggest we let that upload migrate to testing and then fix this. This bug can probably be fixed by passing EGREP="/bin/grep -E" as an additional command-line argument when invoking configure. That was my thought too. It would be nicer to address upstream, but I don't really see a way to do that cleanly short of rewriting it to just use shell built-ins, which seems like a lot of work as it's a hairy beast. Or we could just patch wx-config to set EGREP to "grep -E" (without the path)? https://salsa.debian.org/freewx-team/wx/blob/wx3.0-debian/wx-config.in#L92 Scott
Bug#904111: clamav-daemon causing deadlocks/blocking I/O
On 2018-11-12 10:17:32 [-0800], Adam Lambert wrote: > I believe I already supplied all that way back when I opened up this bug > report. But for reference, here it is again: I tried it back then with no luck. Thanks for the info. I will try to reproduce this asap and get back to you. Sebastian
Bug#914135: distribution-and-changes-mismatch not emitted when it should be
Package: lintian Version: 2.5.112 Patrice Duroux wrote: I was surprise to discover such case of the following package: https://tracker.debian.org/pkg/libnfs for which the unstable and testing versions have the ~exp1 suffix and the head of the corresponding changelog.Debian.gz is: libnfs (2.0.0-1~exp1) experimental; urgency=medium Is this something that may be notified by lintian? Does this need a bug report somewhere? In theory, https://lintian.debian.org/tags/distribution-and-changes-mismatch.html , but since it didn't trigger on libnfs, it would appear to be broken. (If you find any other bugs, please see https://www.debian.org/Bugs/Reporting )
Bug#913953: fixed in the new version qbittorrent 4.1.3-1+b1
fixed 913953 4.1.3-1+b1 thanks
Bug#897348: synaptic still broken
I have had this same problem for months. It would be nice to be able to use synaptics again. Have I missed the response to this bug? The problem is launching from CLI root terminal which used to work. I *can* launch from a GUI menu, but that is overcomplicated for simple things. Running current debian testing. 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux Package: synaptic Status: install ok installed Priority: optional Section: admin Installed-Size: 7810 Maintainer: Michael Vogt Architecture: amd64 Version: 0.84.5 ael
Bug#914127: vlc GUI crashes on several UI operations with same errormessage everytime
Control: tags -1 + moreinfo On 2018-11-19 18:45:08, Ecks Hecker wrote: > Source: vlc > Severity: normal Which version? > >* What led up to the situation? > - trying to open a DVD > or > - trying to open a network stream > or > - trying to save a running stream (the latter initiated from commandline) > >* What exactly did you do (or not do) that was effective (or > ineffective)? > like: open vlc GUI, then select open device (from menu) > >* What was the outcome of this action? > GUI closing without any visible feedback. I had to resort to commandline to > catch an error message > >* What outcome did you expect instead? > play the dvd that was mounted and visible and all > > The error message appearing in all the mentioned cases on terminal: > > ASSERT failure in QList::operator[]: "index out of range", file > /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 545 Please also attach the output of vlc -vvv when the issue happens. Also, since this bug seems to crash vlc with an assertion error, please install the -dbgsym packages and provide the traceback. Thanks! Cheers > > > > -- System Information: > Debian Release: 9.6 > APT prefers proposed-updates > APT policy: (500, 'proposed-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), > LANGUAGE=de_DE.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#914133: perl: Storable probes for user limits at build time, leading to reproducibility issues
clone 914133 -1 reassign -1 jenkins.debian.org retitle -1 reproducible: introduce user limits variations thanks Hi Niko, On Mon, Nov 19, 2018 at 08:40:37PM +0200, Niko Tyni wrote: > It looks like the Storable build (in dist/Storable) probes at build time > for the system stack size limit, and bakes that into the build result > for using it at run time for recursion limit checks. oh dear :) & nice catch! > Copying the reproducible-builds list in case somebody there wants to look > at this. Feel free to fix the usertag if there's a better one. I think 'environment' might be a better one, as in it leaks the environment into the result. > (User limits such as this might be an idea for variations on > tests.reproducible-builds.org variations if they aren't varied already? thats a great idea indeed. any suggestions on which limits to vary and how much? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures
On Mon, Nov 19, 2018 at 03:50:46PM +, James Clarke wrote: > I did this two weeks ago, but it turns out one of the failures > (run/switches.t) > is important, as it reveals that `perl -pi -e ... /tmp/foo` is broken, which > in > turn causes r-base-core's postinst to fail. I've tracked this down and sent a > patch upstream[1]; could you please apply this to the packaging? Thanks! Applied in 5.28.0-4 (just uploaded.) -- Niko
Bug#894056: gconf-editor: Time to remove from Debian?
In my opinion, gconf-editor only makes sense if there are enough "hidden" settings in gconf that aren't exposed in the app's preferences dialog. Now that there are 5 gconf-using packages in Testing (plus 4 with proposed patches), I think it's unlikely for gconf-editor to be needed. Therefore, I'd like to remove gconf-editor from Debian. reverse-depends -- * gpdftext * gyrus * jack-mixer * morris * ogmrip reverse-recommends (for gsettings migration) - * gbonds (proposed patch) * gjiten * gkdebconf * gnome-mastermind * gnomint (proposed patch) * grdesktop * monster-masher * mssh (proposed patch) * planner * xiphos (proposed patch) * zapping Thanks, Jeremy Bicha
Bug#914086: /usr/lib/*/wx/config/*: potentially broken if built on a merged-/usr system and run on a non-merged-/usr system
On Mon, Nov 19, 2018 at 08:32:28AM +, Simon McVittie wrote: > Recent tests on tests.reproducible-builds.org use unmerged /usr for the > first build and merged /usr for the second, as a way to detect some > issues in this class. Thanks for the report. $EGREP is used by the script, and changing it to point to a path that doesn't exists leads to wx-config failing with an error such as: Warning: No config found to match: /usr/bin/wx-config --cppflags in /usr/lib/x86_64-linux-gnu/wx/config I'd actually spotted this (also via reproducible-builds) yesterday but only after I made the recent upload. Unless any of the current buildds has a merged /usr I suggest we let that upload migrate to testing and then fix this. > This bug can probably be fixed by passing EGREP="/bin/grep -E" as an > additional command-line argument when invoking configure. That was my thought too. It would be nicer to address upstream, but I don't really see a way to do that cleanly short of rewriting it to just use shell built-ins, which seems like a lot of work as it's a hairy beast. Cheers, Olly
