Bug#861791: ITP: node-create-ecdh -- create browserifiable ECDH
Package: wnpp Severity: wishlist Owner: Pirate PraveenX-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-create-ecdh Version : 4.0.0 Upstream Author : Calvin Metcalf * URL : https://github.com/crypto-browserify/createECDH * License : Expat Programming Lang: JavaScript Description : create browserifiable ECDH In io.js or node >= 0.11 this module is just a shortcut to crypto.createECDH. In node <= 0.11 or the browser this is a pure JavaScript implimentation, more specifically a wrapper around elliptic to give it the same API as node. . Node.js is an event-based server-side JavaScript engine. signature.asc Description: OpenPGP digital signature
Bug#861788: unblock: libosmium/2.11.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libosmium Upstream has only fixed bugs for this release in line with the freeze policy. (include/attach the debdiff against the package in testing) unblock libosmium/2.11.3-1 Kind Regards, Bas diff -Nru libosmium-2.11.1/CHANGELOG.md libosmium-2.11.3/CHANGELOG.md --- libosmium-2.11.1/CHANGELOG.md 2017-03-07 13:54:48.0 +0100 +++ libosmium-2.11.3/CHANGELOG.md 2017-05-03 14:01:48.0 +0200 @@ -8,6 +8,24 @@ ### Fixed +## [2.11.3] - 2017-05-03 + +### Fixed + +- Two bugs in area assembler affecting very complex multipolygons and + multipolygons with overlapping or nearly overlapping lines. +- Invalid use of iterators leading to undefined behaviour in area assembler + code. +- Read OPL file correctly even if trailing newline in file is missing. + + +## [2.11.2] - 2017-04-10 + +### Fixed + +- Use minimum size of 64 bytes for buffers. This fixes an infinite loop + when buffer size is zero. + ## [2.11.1] - 2017-03-07 @@ -531,7 +549,9 @@ Doxygen (up to version 1.8.8). This version contains a workaround to fix this. -[unreleased]: https://github.com/osmcode/libosmium/compare/v2.11.1...HEAD +[unreleased]: https://github.com/osmcode/libosmium/compare/v2.11.3...HEAD +[2.11.3]: https://github.com/osmcode/libosmium/compare/v2.11.2...v2.11.3 +[2.11.2]: https://github.com/osmcode/libosmium/compare/v2.11.1...v2.11.2 [2.11.1]: https://github.com/osmcode/libosmium/compare/v2.11.0...v2.11.1 [2.11.0]: https://github.com/osmcode/libosmium/compare/v2.10.3...v2.11.0 [2.10.3]: https://github.com/osmcode/libosmium/compare/v2.10.2...v2.10.3 diff -Nru libosmium-2.11.1/CMakeLists.txt libosmium-2.11.3/CMakeLists.txt --- libosmium-2.11.1/CMakeLists.txt 2017-03-07 13:54:48.0 +0100 +++ libosmium-2.11.3/CMakeLists.txt 2017-05-03 14:01:48.0 +0200 @@ -25,7 +25,7 @@ set(LIBOSMIUM_VERSION_MAJOR 2) set(LIBOSMIUM_VERSION_MINOR 11) -set(LIBOSMIUM_VERSION_PATCH 1) +set(LIBOSMIUM_VERSION_PATCH 3) set(LIBOSMIUM_VERSION "${LIBOSMIUM_VERSION_MAJOR}.${LIBOSMIUM_VERSION_MINOR}.${LIBOSMIUM_VERSION_PATCH}") diff -Nru libosmium-2.11.1/debian/changelog libosmium-2.11.3/debian/changelog --- libosmium-2.11.1/debian/changelog 2017-03-07 18:31:00.0 +0100 +++ libosmium-2.11.3/debian/changelog 2017-05-03 18:44:44.0 +0200 @@ -1,3 +1,17 @@ +libosmium (2.11.3-1) unstable; urgency=medium + + * New upstream bugfix release. +- Use minimum size of 64 bytes for buffers. This fixes an infinite + loop when buffer size is zero. +- Two bugs in area assembler affecting very complex multipolygons and + multipolygons with overlapping or nearly overlapping lines. +- Invalid use of iterators leading to undefined behaviour in area + assembler code. +- Read OPL file correctly even if trailing newline in file is missing. + * Update watch file to limit results to 2.11.x releases. + + -- Bas CouwenbergWed, 03 May 2017 18:44:44 +0200 + libosmium (2.11.1-1) unstable; urgency=medium * New upstream bugfix release. diff -Nru libosmium-2.11.1/debian/watch libosmium-2.11.3/debian/watch --- libosmium-2.11.1/debian/watch 2017-03-07 18:23:24.0 +0100 +++ libosmium-2.11.3/debian/watch 2017-05-03 18:38:25.0 +0200 @@ -4,4 +4,4 @@ uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/;s/RC/rc/,\ filenamemangle=s/(?:.*\/)?(?:rel|v|libosmium)[\-\_]?(\d[\d\-\.]+)\.(tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))/libosmium-$1.$2/ \ https://github.com/osmcode/libosmium/releases \ -(?:.*/)?(?:rel|v|libosmium)[\-\_]?(\d[\d\-\.]+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) +(?:.*/)?(?:rel|v|libosmium)[\-\_]?(2\.11\.\d[\d\-\.]*)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) diff -Nru libosmium-2.11.1/include/osmium/area/assembler.hpp libosmium-2.11.3/include/osmium/area/assembler.hpp --- libosmium-2.11.1/include/osmium/area/assembler.hpp 2017-03-07 13:54:48.0 +0100 +++ libosmium-2.11.3/include/osmium/area/assembler.hpp 2017-05-03 14:01:48.0 +0200 @@ -474,17 +474,17 @@ class rings_stack_element { -int32_t m_y; +double m_y; detail::ProtoRing* m_ring_ptr; public: -rings_stack_element(int32_t y, detail::ProtoRing* ring_ptr) : +rings_stack_element(double y, detail::ProtoRing* ring_ptr) : m_y(y), m_ring_ptr(ring_ptr) { } -int32_t y() const noexcept { +double y() const noexcept { return m_y; } @@ -504,7 +504,7 @@ return m_y < rhs.m_y; } -}; // class ring_stack_element +}; // class rings_stack_element using rings_stack = std::vector; @@ -592,7
Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud
Owner: l...@levlaz.org Control: retitle -1 ITP: nextcloud-client -- desktop client for nextcloud
Bug#861787: ITP: node-is-binary-path -- check if a filepath is a binary file
Package: wnpp Severity: wishlist Owner: Pirate PraveenX-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-is-binary-path Version : 2.0.0 Upstream Author : Sindre Sorhus (sindresorhus.com) * URL : https://github.com/sindresorhus/is-binary-path#readme * License : Expat Programming Lang: JavaScript Description : check if a filepath is a binary file This library checks if a filepath is a binary file by checking known binary file extentions list. . Node.js is an event-based server-side JavaScript engine. signature.asc Description: OpenPGP digital signature
Bug#861786: activemq: adjust CVE identifier retrospectively in debian/changelog for 5.14.3-3 upload
Source: activemq Version: 5.14.3-3 Severity: minor Hi activemq maintainers, The CVE id was typoed in the 5.14.3-3 upload. To avoid confusion can you consider adjusting the reference on any next upload of activemq? The correct CVE id was CVE-2015-7559. If you have in your team policy to not ammend older changelog entries, then please close this request. Regards, Salvatore
Bug#861783: dpkg: trying to local divert a file diverted by a package does not work
(If the suggestions below end up not being accepted, then you could simply use your local firefox, and create a dummy package to fulfill dependencies with something like equivs.) Ah yes I suppose I was not clear. The firefox-esr package causes all its depends to be installed, which is what allows the local firefox to run; otherwise the local firefox would have a host of missing depends.
Bug#860660: golang-github-cznic-fileutil: FTBFS on i386: dh_auto_test
control: forwarded -1 https://github.com/cznic/fileutil/issues/16 control: tag -1 +patch Backport the patch from upstream, FTBFS issue seems fixed. So I pushed commit to master (w/o the releasing commit), and mentors branch with the releasing commit. Package is uploaded to mentors for RFS. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpuBZXqjU0Vs.pgp Description: PGP signature
Bug#860660: Pending fixes for bugs in the golang-github-cznic-fileutil package
tag 860660 + pending thanks Some bugs in the golang-github-cznic-fileutil package are closed in revision a8dbbc2c3e52e0d5dae95878a9725b48487b6baf in branch 'master' by Roger Shimizu The full diff can be seen at https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-cznic-fileutil.git/commit/?id=a8dbbc2 Commit message: debian/patches: Add a patch from upstream Patch to fix FTBFS on 32-bit system Closes: #860660
Bug#861785: libreoffice-calc: has high CPU usage and consumes all available memory when closed
Package: libreoffice-calc Version: 1:5.2.6-2 Severity: important Dear Maintainer, * What led up to the situation? Closing LibreOffice-Calc after attempting to swap two columns of text data. * What exactly did you do (or not do) that was effective? 1. Entered 20 text entries in each of the first 3 columns. 2. Highlight the entire 3rd column by selecting the ‘C’ column heading 3. Right clicked and selected Cut to cut the column 3 data. 4. Highlighted the entire 2nd column by selecting the ‘B’ column heading. 5. Right clicked the ‘B’ column heading again and selected Past Special, then selected ‘Right’ under ‘Shift Cells’ and clicked OK. 6. Next, clicked ‘X’ on the Window frame to close the application, and selected discard when prompted to save the spreadsheet. * What was the outcome of this action? The LibreOffice-Calc application window disappeared, and the computer quickly became very sluggish and difficult to use. I opened System-Monitor and found that all available memory was in use (7 GiB), and swap memory was being consumed. I then changed to the Process view, and found there was still an entry for soffice.bin, so I selected that Process entry and clicked 'End Process'. Switching back to the Resoures view, I saw the memory usage immediately drop back down to about 1 GiB, and the computer became responsive again. * What outcome did you expect instead? The LibreOffice-Calc applicatioin would close, and it would release the memory it was using - not start consuming all available memory. * Some additional information. I’ve been able to consistently reproduce this issue on Gnome 3. I can open System-Monitor to the Resources view, open LibreOffice-Calc, perform the steps above, and then watch all memory be consumed in System-Monitor after closing Calc. I can then end the soffice.bin process using System-Monitor, and see the memory usage drop back down. I also attempted to reproduce this issue on Ubuntu Mate 17.04 and on the Solus Budgie desktops, but I could not reproduce it on those desktop environments, but I was able to reproduce it on the Solus Gnome 3 desktop, and Solus currently has a newer version of LibreOffice than is in Debian, so it looks like this may be related to the Gnome 3 desktop environment somehow. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice-calc depends on: ii coinor-libcbc3 2.8.12-1+b2 ii coinor-libcoinmp1v5 1.7.6+dfsg1-2 ii coinor-libcoinutils3v5 2.9.15-4 ii dpkg 1.18.23 ii libblas3 [libblas.so.3] 3.7.0-1 ii libboost-filesystem1.62.01.62.0+dfsg-4 ii libboost-iostreams1.62.0 1.62.0+dfsg-4 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-10 ii libetonyek-0.1-1 0.1.6-5 ii libgcc1 1:6.3.0-14 ii libicu57 57.1-6 ii liblapack3 [liblapack.so.3] 3.7.0-1 ii liblcms2-2 2.8-4 ii libmwaw-0.3-30.3.9-1 ii libodfgen-0.1-1 0.1.6-2 ii liborcus-0.11-0 0.11.2-3+b1 ii libreoffice-base-core1:5.2.6-2 ii libreoffice-core 1:5.2.6-2 ii librevenge-0.0-0 0.0.4-6 ii libstdc++6 6.3.0-14 ii libwps-0.4-4 0.4.5-1 ii libxml2 2.9.4+dfsg1-2.2 ii lp-solve 5.5.0.15-4+b1 ii uno-libs35.2.6-2 ii ure 5.2.6-2 ii zlib1g 1:1.2.8.dfsg-5 libreoffice-calc recommends no packages. Versions of packages libreoffice-calc suggests: pn ocl-icd-libopencl1 Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.7+b1 ii fonts-opensymbol 2:102.7+LibO5.2.6-2 ii libboost-date-time1.62.0 1.62.0+dfsg-4 ii libc6 2.24-10 ii libcairo2 1.14.8-1 ii libclucene-contribs1v52.3.3.4+dfsg-1 ii libclucene-core1v52.3.3.4+dfsg-1 ii libcmis-0.5-5v5 0.5.1+git20160603-3+b1 ii libcups2 2.2.1-8 ii libcurl3-gnutls 7.52.1-5 ii libdbus-1-3 1.10.18-1 ii libdbus-glib-1-2 0.108-2 ii libdconf1 0.26.0-2+b1 ii libeot0 0.01-4+b1 ii libexpat1 2.2.0-2 ii libexttextcat-2.0-0 3.4.4-2+b1 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-14 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libglew2.02.0.0-3+b1 ii libglib2.0-0 2.50.3-2 ii libgltf-0.0-0v5 0.0.2-5 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libgraphite2-31.3.9-4 ii
Bug#861713: netdata: `service netdata restart` fails due to missing pidfile
I use sysvinit (upgraded from wheezy, when it was the default). The init script that `service` calls is "debian/netdata.init" from the source package. Running it directly from init.d has the same effect. May 3, 2017 6:02 AM, "Lennart Weller"wrote: > What init do you use on your system? > The creation of the pid file should have been done by the init. > > May 3, 2017 5:09 AM, "Daniel Ring" wrote: > >> Package: netdata >> Version: 1.5.0+dfsg-4 >> Severity: normal >> >> Dear Maintainer, >> >> The init scripts provided with this package do not seem to work properly. >> I reported this bug upstream at >> https://github.com/firehol/netdata/issues/2135, but the init >> scripts provided with this package have been modified for Debian so I'm not >> sure where the issue >> first arose. >> The directory "/var/run/netdata" is not created by default on my system. >> Creating it and chowning >> to netdata:netdata had no effect. >> >> Running `service netdata restart` results in the following output: >> [ ok ] Stopping the netdata daemon...done (not running - there is no >> /var/run/netdata/netdata.pid). >> [] Starting the netdata daemon...2017-05-02 19:55:59: netdata: ERROR: >> IPv4 bind() on ip >> '127.0.0.1' port 1 failed. (errno 98, Address already in use) >> 2017-05-02 19:55:59: netdata: ERROR: Cannot bind to ip '127.0.0.1', port >> 1 >> 2017-05-02 19:55:59: netdata: FATAL: Cannot listen on any socket. Exiting... >> # : Success >> >> 2017-05-02 19:55:59: netdata: INFO: Saving database... >> 2017-05-02 19:55:59: netdata: INFO: netdata exiting. Bye bye... >> failed. >> >> Running `service netdata stop` results in the following output: >> [ ok ] Stopping the netdata daemon...done (not running - there is no >> /var/run/netdata/netdata.pid). >> >> A netdata instance is running normally in the background in both cases. >> Running `service netdata start` works as expected. >> >> -- System Information: >> Debian Release: 8.7 >> APT prefers stable-updates >> APT policy: (500, 'stable-updates'), (500, 'stable') >> Architecture: i386 (i686) >> >> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: sysvinit (via /sbin/init) >> >> Versions of packages netdata depends on: >> ii adduser 3.113+nmu3 >> ii init-system-helpers 1.22 >> ii libc6 2.19-18+deb8u7 >> ii libcap2-bin 1:2.24-8 >> ii libuuid1 2.25.2-6 >> ii lsb-base 4.1+Debian13+nmu1 >> ii netdata-data 1.5.0+dfsg-4 >> ii python 2.7.9-1 >> ii python-yaml 3.11-2 >> ii zlib1g 1:1.2.8.dfsg-2+b1 >> >> Versions of packages netdata recommends: >> pn nodejs >> >> netdata suggests no packages. >> >> -- Configuration Files: >> /etc/netdata/netdata.conf changed [not included] >> >> -- no debconf information
Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.
On Thursday, May 4, 2017 4:53:52 AM CEST Ondřej Surý wrote: > And output of: > > pgrep mysqld > > does it return the same pid as pidof command? > > Cheers, It think you are right, there are 2 processes: # ps uax | egrep $(pidof /usr/sbin/mysqld|tr ' ' '|') # as root chris 6177 0.5 1.7 606652 141384 ? Sl 03:20 0:40 /usr/sbin/mysqld --defaults-file=/home/chris/.local/share/akonadi/mysql.conf --datadir=/home/chris/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-chris.UBoT4r/mysql.socket mysql11527 0.3 0.9 669628 74320 ?Ssl 05:17 0:00 /usr/sbin/mysqld When I do, as in the "prerm" script: invoke-rc.d mysql stop it stops only the mysqld of user mysql (no matter how many times) and pidof -c /usr/sbin/mysqld continues to give a positive answer. However, initially, pidof -c /usr/sbin/mysqld # (with -c, on two lines, w/o one the same line) was giving two pid. But when done after the invoke-rc.d mysql stop it gives only one pid. So it might be, that at that point, installation could keep going, instead of stopping. Also the two processes are own by different users, so they are easy to differentiate in a test. Best, Chris
Bug#861576: new dpkg colourized output doesn't respect /etc/terminal-colors.d/disable
Control: severity -1 wishlist On Mon, 2017-05-01 at 08:57:10 +0200, Sven Joachim wrote: > On 2017-04-30 18:47 -0400, Brad Barnett wrote: > > Package: dpkg > > Version: 1.18.23 > > > > Newer versions of dpkg have colourized output. > > > > I can see the usage case for this, and I can see the value for some. > > > > However, for others, it is a major detractor. > > > > One of the issues with the recent colourization of the userland, is that > > each has its own way to disable it. > > > > Which is why /etc/terminal-colors.d/disable exists, as far as I can see. > > > > Yet, dpkg does not respect /etc/terminal-colors.d/disable. dmesg does. > > Lots of other packages do. > > AFAICS, those "lots of other packages" are all built from the same > source package, namely util-linux[1]. So this is far from standardized. Indeed, went through the same process of searching on codesearch and then checking the man page, and reaching some blog posts from util-linux upstream briefly describing this stuff. Will need to check if there's other alternative prior art and similar. I'm a bit undecided about this though, in a way it sounds nice, but dunno. Thanks, Guillem
Bug#861783: dpkg: trying to local divert a file diverted by a package does not work
Control: reassign -1 firefox,firefox-esr Control: retitle -1 firefox: Usage of diversions disallows more than two installed implementations Control: severity -1 wishlist Hi! On Wed, 2017-05-03 at 18:48:34 -0700, Joshua wrote: > Package: dpkg > Version: 1.18.23 > Severity: normal >* What led up to the situation? > > firefox-esr has a diversion of /usr/bin/firefox; and package firefox-esr > must be installed for dependency resolution; however I actually need > to use a package of firefox that doesn't have a .dpkg > > So I try dpkg-divert /usr/bin/firefox > > Nope! (If the suggestions below end up not being accepted, then you could simply use your local firefox, and create a dummy package to fulfill dependencies with something like equivs.) >* What exactly did you do (or not do) that was effective (or > ineffective)? > > All variants of dpkg-divert that remotely made sense to try. > > I tried reading the source code to determine if I could safely knock > the check out. This was inconclusive as I don't understand it well enough > to tell what would happen. The problem is that diversion are not stackable, so only a couple of packages providing the same pathname can be installed at the same time, if there's need for more then those should be using alternatives for example. >* What was the outcome of this action? > > Frustration. > >* What outcome did you expect instead? > > let go of /usr/bin/firefox so I could add symlink > /usr/bin/firefox -> /usr/local/lib/firefox/firefox That's something for the firefox maintainers to decide. Thanks, Guillem
Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.
And output of: pgrep mysqld does it return the same pid as pidof command? Cheers, -- Ondřej SurýKnot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Thu, May 4, 2017, at 04:40, Ondřej Surý wrote: > Chris, > > I don't use KDE, so I will need a little of your help. > > Could you do on a running system: > > ps uax | grep $(pidof -c /usr/sbin/mysqld) > > and > > is there a difference between: > > pidof /usr/sbin/mysqld > > and > > pidof -c /usr/sbin/mysqld > > ? > > Cheers, > -- > Ondřej Surý > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server > Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, > fast DNS(SEC) resolver > Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro > pečení chleba všeho druhu > > On Thu, May 4, 2017, at 03:17, chris wrote: > > Package: mariadb-server-10.1 > > Version: 10.1.22-4 > > Severity: important > > > > Dear Maintainer, > > > > Upgrade from 1 month old version failed. > > > > Installation says: > > > > There is a MySQL server running, but we failed in our attempts to stop > > it. > > Stop it yourself and try again! > > > > and fails. > > > > When looking at: > > /var/lib/dpkg/info/mariadb-server-10.1.prerm > > one can see: > > invoke-rc.d mysql stop > > pidof -c /usr/sbin/mysqld > > > > Executing those lines myself, I get: > > # invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld > > 3174 > > > > Similarly: > > # systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld > > 3174 > > > > However I could stop the sever as a plain user: > > $ akonadictl stop > > > > Verify it is stopped: > > # pidof -c /usr/sbin/mysqld > > > > Then the upgrade worked flawlessly: > > # apt-get upgrade > > > > A very verbose description can be found there: > > https://lists.debian.org/debian-kde/2017/05/msg0.html > > > > > > Best, > > Chris > > > > > > > > -- System Information: > > Debian Release: 9.0 > > APT prefers unstable > > APT policy: (500, 'unstable'), (500, 'testing') > > Architecture: amd64 > > (x86_64) > > > > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: > > LC_ALL set to en_US.UTF-8) > > 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.60 > > ii galera-3 25.3.20-1 > > ii gawk 1:4.1.4+dfsg-1 > > ii init-system-helpers 1.48 > > ii iproute2 4.9.0-1 > > ii libaio1 0.3.110-3 > > ii libc6 2.24-10 > > ii libdbi-perl 1.636-1+b1 > > ii libpam0g 1.1.8-3.5 > > ii libstdc++66.3.0-16 > > ii lsb-base 9.20161125 > > ii lsof 4.89+dfsg-0.1 > > ii mariadb-client-10.1 10.1.22-4 > > ii mariadb-common10.1.22-4 > > ii mariadb-server-core-10.1 10.1.22-4 > > ii passwd1:4.4-4 > > ii perl 5.24.1-2 > > ii psmisc22.21-2.1+b2 > > ii rsync 3.1.2-2 > > ii socat 1.7.3.1-2+b1 > > ii zlib1g1:1.2.8.dfsg-5 > > > > Versions of packages mariadb-server-10.1 recommends: > > ii libhtml-template-perl 2.95-2 > > > > 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 > > > > -- debconf information: > > mariadb-server-10.1/postrm_remove_databases: false > > mariadb-server-10.1/nis_warning: > > mariadb-server-10.1/old_data_directory_saved: > > >
Bug#851877: fails every time
Control: severity -1 serious Looks like for some reason it switched to failing 100% of the time now -- or at least it does so on all of my setups. I have yet to see the build succeed, despite tens of attempts on amd64, armhf and i386. The fail reason is same as in your report: cat: /tmp/sslh_test.pid: No such file or directory killing Can't kill a non-numeric process ID at ./t line 221. (then it hangs until sbuild kills it) > The bug should be reproducible with sbuild on a single CPU virtual > machine, provided you try enough times (as the failure happens randomly). All of my sbuilds are on real metal, at least four cores; DEB_BUILD_OPTIONS=parallel=XXX is set appropriately. Meow! -- Don't be racist. White, amber or black, all beers should be judged based solely on their merits. Heck, even if occasionally a cider applies for a beer's job, why not? On the other hand, corpo lager is not a race.
Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.
Chris, I don't use KDE, so I will need a little of your help. Could you do on a running system: ps uax | grep $(pidof -c /usr/sbin/mysqld) and is there a difference between: pidof /usr/sbin/mysqld and pidof -c /usr/sbin/mysqld ? Cheers, -- Ondřej SurýKnot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Thu, May 4, 2017, at 03:17, chris wrote: > Package: mariadb-server-10.1 > Version: 10.1.22-4 > Severity: important > > Dear Maintainer, > > Upgrade from 1 month old version failed. > > Installation says: > > There is a MySQL server running, but we failed in our attempts to stop > it. > Stop it yourself and try again! > > and fails. > > When looking at: > /var/lib/dpkg/info/mariadb-server-10.1.prerm > one can see: > invoke-rc.d mysql stop > pidof -c /usr/sbin/mysqld > > Executing those lines myself, I get: > # invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld > 3174 > > Similarly: > # systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld > 3174 > > However I could stop the sever as a plain user: > $ akonadictl stop > > Verify it is stopped: > # pidof -c /usr/sbin/mysqld > > Then the upgrade worked flawlessly: > # apt-get upgrade > > A very verbose description can be found there: > https://lists.debian.org/debian-kde/2017/05/msg0.html > > > Best, > Chris > > > > -- System Information: > Debian Release: 9.0 > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 > (x86_64) > > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8) > 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.60 > ii galera-3 25.3.20-1 > ii gawk 1:4.1.4+dfsg-1 > ii init-system-helpers 1.48 > ii iproute2 4.9.0-1 > ii libaio1 0.3.110-3 > ii libc6 2.24-10 > ii libdbi-perl 1.636-1+b1 > ii libpam0g 1.1.8-3.5 > ii libstdc++66.3.0-16 > ii lsb-base 9.20161125 > ii lsof 4.89+dfsg-0.1 > ii mariadb-client-10.1 10.1.22-4 > ii mariadb-common10.1.22-4 > ii mariadb-server-core-10.1 10.1.22-4 > ii passwd1:4.4-4 > ii perl 5.24.1-2 > ii psmisc22.21-2.1+b2 > ii rsync 3.1.2-2 > ii socat 1.7.3.1-2+b1 > ii zlib1g1:1.2.8.dfsg-5 > > Versions of packages mariadb-server-10.1 recommends: > ii libhtml-template-perl 2.95-2 > > 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 > > -- debconf information: > mariadb-server-10.1/postrm_remove_databases: false > mariadb-server-10.1/nis_warning: > mariadb-server-10.1/old_data_directory_saved: >
Bug#861784: bluez: bluetooth headphones change from A2DP to hsp after about 30 minutes of playing music
Package: bluez Version: 5.43-2 Severity: important Dear Maintainer, * What led up to the situation? I connected to the A2DP sink on my BoatRockerz 600 headphones using blueman and began playing music using Audacious. After about half an hour the sound output suddenly became distorted. * What exactly did you do (or not do) that was effective (or ineffective)? I re-paired the device and reconnected to the A2DP sink. * What was the outcome of this action? It worked and the distortion was gone. * What outcome did you expect instead? The audio playback should have continued smoothly. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.utf8, LC_CTYPE=en_IN.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bluez depends on: ii dbus 1.10.18-1 ii init-system-helpers 1.47 ii kmod 23-2 ii libc62.24-10 ii libdbus-1-3 1.10.18-1 ii libglib2.0-0 2.50.3-2 ii libreadline7 7.0-2 ii libudev1 232-22 ii lsb-base 9.20161125 ii udev 232-22 bluez recommends no packages. Versions of packages bluez suggests: ii pulseaudio-module-bluetooth 10.0-1 -- no debconf information
Bug#174331: macro support
patch against git master I had to changed my rsyslog format recently and logcheck is near to unusable if I need to change/duplicate/transform all the rules From 9fa05bd1202418da3a279c9f3bfe2a7c192e43c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Droz?=Date: Wed, 3 May 2017 22:45:02 -0300 Subject: [PATCH] added a MACRO expand system. Just add bash-style variable definition inside $RULEDIR/macros. logcheck-test -r support using a -m flag --- src/logcheck | 12 src/logcheck-test | 30 ++ 2 files changed, 42 insertions(+) diff --git a/src/logcheck b/src/logcheck index a8c58ea..4a70773 100755 --- a/src/logcheck +++ b/src/logcheck @@ -223,6 +223,11 @@ cleanrules() { error "Couldn't read $x" fi done + + if [[ -n $RULEDIR/macros ]]; then + { cat "$RULEDIR/macros" && echo "read -r -d '' str <<__EOF__"; } > "$cleaned/$rulefile" + fi + for rulefile in $(run-parts --list "$dir"); do rulefile="$(basename "$rulefile")" if [ -f "${dir}/${rulefile}" ]; then @@ -233,6 +238,13 @@ cleanrules() { || error "Couldn't append to $cleaned/$rulefile." fi done + + if [[ -n $RULEDIR/macros ]]; then + echo -e '__EOF__\necho "$str";' >> "$cleaned/$rulefile"; + /usr/bin/env bash "$cleaned/$rulefile" > "$cleaned/$rulefile.tmp" + mv -f "$cleaned/$rulefile.tmp" "$cleaned/$rulefile" + fi + elif [ -f "$dir" ]; then error "cleanrules: '$dir' is a file, not a directory" elif [ -z "$dir" ]; then diff --git a/src/logcheck-test b/src/logcheck-test index 288fbb8..e84c76a 100755 --- a/src/logcheck-test +++ b/src/logcheck-test @@ -24,6 +24,7 @@ FILE= PREFIX= SUFFIX= RULEFILE= +MACROFILE= INVERT= RULE= @@ -48,6 +49,7 @@ usage: logcheck-test -S|--prepend-suffix SUFFIX : Prepend SUFFIX to rule suffix -r|--rule-file RULEFILE : Use file RULEFILE for rule input +-m|--macro-file MACROFILE : Use file MACROFILE for macros (only with --rule-file) EOF } @@ -79,6 +81,22 @@ while [ -n "${1:-}" ]; do shift fi ;; +-m|--macro-file) +if [ -z "${1:-}" ] ; then +err "$ARGUMENT needs an rule file as argument" +exit 4 +else +MACROFILE="$1" +if ! [ -f "$MACROFILE" -o -L "$MACROFILE" ] ; then +err "'$MACROFILE' is nor a regular file nor a symbolic link" +exit 5 +elif ! [ -r "$MACROFILE" ] ; then +err "'$MACROFILE' permission denied" +exit 6 +fi +shift +fi +;; -l|--log-file) if [ -z "${1:-}" ] ; then err "$ARGUMENT needs a log file as argument" @@ -178,7 +196,19 @@ else if [ -n "$RULEFILE" ] ; then CLEANRULE="$(mktemp "${TMPDIR:-/tmp}/logcheck-test.XX")" cleanup() { rm -rf $CLEANRULE; } + + if [ -n "$MACROFILE" ]; then + { cat "$MACROFILE" && echo "read -r -d '' str <<__EOF__"; } > "$CLEANRULE" + fi + egrep --text -v '^[[:space:]]*$|^#' "$RULEFILE" >> $CLEANRULE + + if [ -n "$MACROFILE" ]; then + /bin/echo -e '__EOF__\necho "$str";' >> "$CLEANRULE" + /usr/bin/env bash "$CLEANRULE" > "$CLEANRULE.tmp" + mv -f "$CLEANRULE.tmp" "$CLEANRULE" + fi + sed -e 's/[[:space:]]*$//' $FILE | egrep $INVERT -f "$CLEANRULE" GREP="$?" cleanup -- 2.1.4
Bug#861783: dpkg: trying to local divert a file diverted by a package does not work
Package: dpkg Version: 1.18.23 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? firefox-esr has a diversion of /usr/bin/firefox; and package firefox-esr must be installed for dependency resolution; however I actually need to use a package of firefox that doesn't have a .dpkg So I try dpkg-divert /usr/bin/firefox Nope! * What exactly did you do (or not do) that was effective (or ineffective)? All variants of dpkg-divert that remotely made sense to try. I tried reading the source code to determine if I could safely knock the check out. This was inconclusive as I don't understand it well enough to tell what would happen. * What was the outcome of this action? Frustration. * What outcome did you expect instead? let go of /usr/bin/firefox so I could add symlink /usr/bin/firefox -> /usr/local/lib/firefox/firefox *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8.1 ii libc62.24-10 ii liblzma5 5.2.2-1.2+b1 ii libselinux1 2.6-3+b1 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-5 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.4.1 pn debsig-verify -- no debconf information
Bug#861782: mariadb-server-10.1: Upgrade fails because mariadb-server-10.1.prerm fails to stop mysqld.
Package: mariadb-server-10.1 Version: 10.1.22-4 Severity: important Dear Maintainer, Upgrade from 1 month old version failed. Installation says: There is a MySQL server running, but we failed in our attempts to stop it. Stop it yourself and try again! and fails. When looking at: /var/lib/dpkg/info/mariadb-server-10.1.prerm one can see: invoke-rc.d mysql stop pidof -c /usr/sbin/mysqld Executing those lines myself, I get: # invoke-rc.d mysql stop; pidof -c /usr/sbin/mysqld 3174 Similarly: # systemctl stop mariadb.service; pidof -c /usr/sbin/mysqld 3174 However I could stop the sever as a plain user: $ akonadictl stop Verify it is stopped: # pidof -c /usr/sbin/mysqld Then the upgrade worked flawlessly: # apt-get upgrade A very verbose description can be found there: https://lists.debian.org/debian-kde/2017/05/msg0.html Best, Chris -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) 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.60 ii galera-3 25.3.20-1 ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii iproute2 4.9.0-1 ii libaio1 0.3.110-3 ii libc6 2.24-10 ii libdbi-perl 1.636-1+b1 ii libpam0g 1.1.8-3.5 ii libstdc++66.3.0-16 ii lsb-base 9.20161125 ii lsof 4.89+dfsg-0.1 ii mariadb-client-10.1 10.1.22-4 ii mariadb-common10.1.22-4 ii mariadb-server-core-10.1 10.1.22-4 ii passwd1:4.4-4 ii perl 5.24.1-2 ii psmisc22.21-2.1+b2 ii rsync 3.1.2-2 ii socat 1.7.3.1-2+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-server-10.1 recommends: ii libhtml-template-perl 2.95-2 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 -- debconf information: mariadb-server-10.1/postrm_remove_databases: false mariadb-server-10.1/nis_warning: mariadb-server-10.1/old_data_directory_saved:
Bug#861781: www.debian.org: updating Debian memberships in other organisations information
Package: www.debian.org Severity: wishlist The list of Debian memberships on our website is outdated. https://www.debian.org/misc/memberships We might want to: Replace the representatives that are retired* from Debian: GNOME Foundation (representative: Matthew Garrett*) Linux Standards Base (representative: Wichert Akkerman*) SchoolForge (representatives: Ben Armstrong*, Raphaël Hertzog) OASIS: Organization for the Advancement of Structured Information Standards (representative: Mark Johnson*) Reconfirm the involvement of these representatives: Linux International (representative: Ean R. Schuessler) Linux Professional Institute (representative: Christoph Lameter) SchoolForge (representatives: Ben Armstrong*, Raphaël Hertzog) OVAL: Open Vulnerability Assessment Language (representative: Javier Fernández-Sanguino) Find out who our representatives are for these organisations: Linux Magazine advisory council Discuss membership possibilities with: Linux Foundation (the Free Standards Group got merged into LF) Add other organisations that Debian has representatives in. Look at which other organisations Debian may want membership in. Remove these organisations that no longer exist: Desktop Linux Consortium (representative: Colin Walters*) -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]
在 2017年5月4日星期四 +08 上午8:09:13,Paul Wise 写道: > The README is pretty clear that the fonts are compile to OpenType using > AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian > main so this font should go to contrib. In addition, no FontForge > source format or SVG files were released and the font is under the > GPL so I don't think we can distribute this at all. Please ask the > ftp-masters to reject this package from NEW. That's a pity. I'm contacting upstream author to see what we can do next. (e.g. releasing proper src and/or help packaging AFDKO #762252). -- Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#861685: bilibop-common: Fails to detect boot device on systems with 2+ aufs read-only branches
Hi, On 02/05/2017 19:50, intrig...@debian.org wrote: > > It seems that some part of bilibop got confused and we get a string > with two paths separated by a newline, where there should be only one > path, no? Yes. It seems the bug has been introduced at commit 03a49203282, between versions 0.4.23 (in jessie) and 0.5.0. > Downgrading to Jessie's bilibop fixes the problem… but it might > introduce other problems, can't it? Probably not in this case. Changes since 0.4.23 are about overlayfs support, btrfs support, and documentation updates, typos, packaging and so on. If you use aufs to manage incremental upgrades, I suppose you don't use overlayfs ? For the case you have an entry point to easily add a patch in your build process, try the attached file. It may also be tested quickly from a Tails session with: # cd / # patch -p1 < /path/to/bilibop-bugfix861685-01.patch # /lib/bilibop/disk / # /lib/bilibop/test / I will test it too in a few days. Thanks for your detailed bug report, quidame diff --git a/lib/bilibop/common.sh b/lib/bilibop/common.sh index 5f9e4bb..589f177 100644 --- a/lib/bilibop/common.sh +++ b/lib/bilibop/common.sh @@ -513,24 +513,31 @@ underlying_device_from_loop() { # branch of an aufs mountpoint given as argument. We assume that there is only # and at least one physical device used to build the aufs (but the directory # is not necessarly the mountpoint of this device), other branch(s) being -# virtual fs. +# virtual fs. Note that if there are more than one readonly branch, the first +# block device found wins. underlying_device_from_aufs() { ${DEBUG} && echo "> underlying_device_from_aufs $@" >&2 -local dir="$(aufs_readonly_branch "${1}")" -local dev="$(device_id_of_file "${dir}")" -case "${dev}" in -"") -;; -0:*) -# aufs mounts can't be nested; but this may be btrfs -dev="$(underlying_device_from_file "${dir}")" -;; -*) -dev="$(device_node_from_major_minor "${dev}")" -;; -esac - -[ -b "${dev}" ] && readlink -f "${dev}" +local dev dir +for dir in $(aufs_readonly_branch "${1}"); do +dev="$(device_id_of_file "${dir}")" +case "${dev}" in +"") +continue +;; +0:*) +# aufs mounts can't be nested; but this may be btrfs +dev="$(underlying_device_from_file "${dir}")" +;; +*) +dev="$(device_node_from_major_minor "${dev}")" +;; +esac +if [ -b "${dev}" ]; then +readlink -f "${dev}" +return 0 +fi +done +return 1 } # ===}}} # underlying_device_from_overlayfs() {{{ signature.asc Description: OpenPGP digital signature
Bug#861779: ITP: tss2 -- IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities
Control: reassign -1 wnpp ITP bugs should be assigned to 'wnpp', not the nonexistent package. See https://www.debian.org/devel/wnpp/ Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]
On Thu, 4 May 2017 00:38:24 +0200 Adam Borowski wrote: > I'm not entirely sure .otf are the real sources, despite the upstream > providing only otf. For now, let's assume they are, unless there's evidence > to the contrary (not sure what the README means). The README is pretty clear that the fonts are compile to OpenType using AFDKO from FontForge and or Inkscape source. AFDKO is not in Debian main so this font should go to contrib. In addition, no FontForge source format or SVG files were released and the font is under the GPL so I don't think we can distribute this at all. Please ask the ftp-masters to reject this package from NEW. Here are the contents of the README for the record: README These are the Fandol fonts for Chinese typesetting. Current version of Fandol fonts contains four styles: Song, Hei, Kai, Fang. All the fonts are OpenType. These fonts are developed by Fandol team. The member of Fandol team: Clerk Ma & Jie Su. These fonts's licensing is GPL + GPL font exception. CHANGELOG v0.1 2013/07/31 * initital version. v0.2 2013/08/03 * change GID to CID (Adobe-GB1-5) * using AFDKO to compile to OpenType * CID ranges: 940-7702, 7717-8895, 29064-30220 * XUID: 1440 * fontforge + inkscape as outline editor v0.3 2015/07/18 * added two braille fonts * fixed bugs of kanji fonts -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#860554: autopkgtest: Running autopkgtest may fail due to long path
Control: tags -1 patch Hi Antonio, On Thu, Apr 27, 2017 at 2:49 PM, Antonio Terceirowrote: > On Tue, Apr 18, 2017 at 03:50:15PM +0200, Balint Reczey wrote: >> Package: autopkgtest >> Version: 4.3 >> >> Dear Maintainers, >> >> Running autopkgtest testsuite of libdbd-mysql-perl fails on s390x due >> to the long socket filename: >> >> ( From https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1680577 ) >> ... >> 2017-03-29T08:40:18.627231Z 0 [Warning] Failed to set up SSL because >> of the following SSL library error: SSL context is not usable without >> certificate and private key >> 2017-03-29T08:40:18.627257Z 0 [ERROR] The socket file path is too long >> (> 107): >> /data/adttmp/autopkgtest-virt-lxc.shared.y4ui3net/downtmp/build.R3s/libdbd-mysql-perl-4.041/t/testdb/mysql.sock >> 2017-03-29T08:40:18.627267Z 0 [ERROR] Aborting >> >> 2017-03-29T08:40:18.627278Z 0 [Note] Binlog end >> 2017-03-29T08:40:18.627315Z 0 [Note] Shutting down plugin 'ngram' >> 2017-03-29T08:40:18.627328Z 0 [Note] Shutting down plugin 'partition' >> 2017-03-29T08:40:18.627337Z 0 [Note] Shutting down plugin 'BLACKHOLE' >> ... >> >> A few characters could be cut in the package's test itself, but the >> same problem may affect many other packages and fixing the issue in >> autopkgtest seems bring more benefits. >> >> The system configuration addst the beginning of the path, but it is >> not very long compared to the standard "/tmp": >> "/data/adttmp/" >> >> The test itself generates the following path inside the source >> directory which is not a huge portion of the path either: >> "t/testdb/mysql.sock" >> >> Autopkgtest generates the longest part: >> "autopkgtest-virt-lxc.shared.y4ui3net/downtmp/build.R3s/libdbd-mysql-perl-4.041" >> >> I proposed a patch which cuts a few characters from the prefix by >> abbreviating "autopkgtest-virt-lxc.shared.", but the source directory >> for the package could also be just "src" instead of the full package >> name with version especially since this can be much longer than in the >> current case. >> >> Before preparing an updated patch I wanted to ask for your opinion >> regarding the path to be taken ( :-) ). > > I am not an autopkgtest maintainer, but I think we could maybe have the > source tree in a very short path right on top of /, like /src, or > /autopkgtest/src ... however I am not sure how that would impact the > current codebase. I have implemented this in the attached patch. I hope the maintainter likes it as it worked nicely for me. Cheers, Balint -- Balint Reczey Debian & Ubuntu Developer From cf86f2f2f640dd2880c41c73e2b90afbbf2abdb9 Mon Sep 17 00:00:00 2001 From: Balint Reczey Date: Thu, 4 May 2017 02:01:56 +0200 Subject: [PATCH] Use ".../src" as temporary package build directory instead of -. This makes build path predictably shorter. Closes: #860554 --- runner/autopkgtest | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/runner/autopkgtest b/runner/autopkgtest index 2f43446..fe7e93d 100755 --- a/runner/autopkgtest +++ b/runner/autopkgtest @@ -321,7 +321,7 @@ def build_source(kind, arg, built_binaries): p = adt_testbed.Path(testbed, part, os.path.join(testbed.scratch, os.path.basename(part))) p.copydown() -create_command = 'dpkg-source -x "%s"' % dsc_tb +create_command = 'dpkg-source -x "%s" src' % dsc_tb elif kind == 'unbuilt-tree': dsc = os.path.join(tmp, 'fake.dsc') @@ -385,10 +385,10 @@ def build_source(kind, arg, built_binaries): ' ver=${srcversion:-$pkg_candidate};' ' dpkg --compare-versions "$ver" lt "$maxver" || maxver="$ver";' 'done;' - '[ -z "$maxver" ] || maxver="=$maxver";' - 'OUT=$(apt-get source -q --only-source %(src)s$maxver 2>&1) || RC=$?;' + '[ -z "$maxver" ] || maxver="$maxver";' + 'OUT=$(apt-get source -d -q --only-source %(src)s=$maxver 2>&1) || RC=$?;' 'if [ -n "$RC" ]; then if echo "$OUT" | grep -q "Unable to find a source package"; then exit 1; else exit $RC; fi; fi;' - 'echo "$OUT" | grep ^Get: || true' % {'src': arg}) + 'echo "$OUT" | grep ^Get: ; dpkg-source -x %(src)s_$maxver.dsc src' % {'src': arg}) elif kind == 'git-source': url, _, branch = arg.partition('#') create_command = "git clone '%s' || { sleep 15; git clone '%s'; }" % (url, url) -- 2.7.4
Bug#861780: README does not mention pause key combo
Package: kazam Version: 1.4.5-2 Severity: normal The README documents some keyboard shortcuts, but no the one for pausing which is SUPER-CTRL-P -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kazam depends on: ii gir1.2-gst-plugins-base-1.0 1.10.4-1 ii gir1.2-gstreamer-1.0 1.10.4-1 ii gir1.2-keybinder-3.0 0.3.1-1 ii gir1.2-wnck-3.0 3.20.1-3 ii gnome-session-canberra 0.30-3 ii gstreamer1.0-plugins-base1.10.4-1 ii gstreamer1.0-plugins-good1.10.4-1 ii gstreamer1.0-plugins-ugly1.10.4-1 ii gstreamer1.0-pulseaudio 1.10.4-1 ii python3 3.5.3-1 ii python3-cairo1.10.0+dfsg-5+b1 ii python3-dbus 1.2.4-1+b1 ii python3-gi 3.22.0-2 ii python3-gi-cairo 3.22.0-2 ii python3-xdg 0.25-4 pn python3:any Versions of packages kazam recommends: ii gstreamer1.0-libav 1.10.4-1 kazam suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#859524: libpfm4: Unexpected libpfm abi change between libpfm-4.7 and libpfm-4.8
On 2017-04-11 22:07, Andreas Beckmann wrote: > I just uploaded a git snaphot reverting the abi change (and implementing > an alternate solution) plus an s390x patch from the mailing list to > experimental. If that builds everywhere and 4.9 doesn't come in time, > I'll upload it to unstable. And thereafter upload papi with a bumped > build dependency. 4.9 didn't get released so far, therefore a new libpfm4 snapshot (including the s390x patch) is now in unstable and a papi with a bumped B-D, too. Andreas
Bug#861765: papi FTBFS on s390x: OVERFLOW_ADDRESS() and _papi_hwd_lock/unlock undefined!
Control: tag -1 upstream wontfix Control: severity -1 wishlist On 2017-05-03 20:45, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=papi=s390x That never succeeded. Upstream does not support s390x. And I won't accept any third-party patches for this. Andreas
Bug#861779: ITP: tss2 -- IBM's TCG Software Stack (TSS) for TPM 2.0 and related utilities
X-Debbugs-CC: debian-de...@lists.debian.org Package: tss2 Version: 851 Severity: wishlist I plan to create a new package, tss2, which is developed by Kenneth Goldman from IBM. TSS2 is a user space Trusted Computing Group's Software Stack (TSS) for TPM 2.0. It implements the functionality equivalent to the TCG TSS working group's ESAPI, SAPI, and TCTI layers (and perhaps more) but with a hopefully far simpler interface. It comes with about 80 "TPM tools" that can be used for rapid prototyping, education and debugging. The package is of BSD license. The following is the current URL for the upstream package: https://sourceforge.net/projects/ibmtpm20tss/files/ibmtss851.tar Best Regards, Vicky
Bug#861778: CTRL-S doesn't save file
Package: midori Version: 0.5.12~wk2-exp1 $ midori . #browse current directory CTRL-S #and choose /tmp as the place to save it. $ ls /tmp #no file saved.
Bug#861777: unblock: telepathy-qt/0.9.6.1-6.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package telepathy-qt The package has a FTBFS RC bug on some architectures (https://bugs.debian.org/859462) which is fixed with this upload. unblock telepathy-qt/0.9.6.1-6.1 Regards, Tobias diff -Nru telepathy-qt-0.9.6.1/debian/changelog telepathy-qt-0.9.6.1/debian/changelog --- telepathy-qt-0.9.6.1/debian/changelog 2016-04-06 20:14:17.0 +0200 +++ telepathy-qt-0.9.6.1/debian/changelog 2017-05-03 22:56:53.0 +0200 @@ -1,3 +1,11 @@ +telepathy-qt (0.9.6.1-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add fix-failing-test.patch to fix failing tests on some architectures +(Closes: #859462) + + -- Dr. Tobias QuathamerWed, 03 May 2017 22:56:53 +0200 + telepathy-qt (0.9.6.1-6) unstable; urgency=medium * Add fix-deprecated-bsd-source.patch diff -Nru telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch --- telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch 1970-01-01 01:00:00.0 +0100 +++ telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch 2017-05-03 22:53:06.0 +0200 @@ -0,0 +1,15 @@ +Author: David Edmundson +Description: Use C++ bool type rather than mixing with gboolean + They are not always the same size. + This fixes a compile error on some systems. +--- a/tests/dbus/contacts-capabilities.cpp b/tests/dbus/contacts-capabilities.cpp +@@ -111,7 +111,7 @@ + QStringList ids = QStringList() << QLatin1String("alice") + << QLatin1String("bob") << QLatin1String("chris"); + +-gboolean supportTextChat[] = { TRUE, FALSE, FALSE }; ++bool supportTextChat[] = { true, false, false }; + + TpHandleRepoIface *serviceRepo = + tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()), diff -Nru telepathy-qt-0.9.6.1/debian/patches/series telepathy-qt-0.9.6.1/debian/patches/series --- telepathy-qt-0.9.6.1/debian/patches/series 2016-03-25 21:55:06.0 +0100 +++ telepathy-qt-0.9.6.1/debian/patches/series 2017-05-03 22:53:27.0 +0200 @@ -3,3 +3,4 @@ gstreamer-1.5.patch force-service-pic.patch fix-deprecated-bsd-source.patch +fix-failing-test.patch signature.asc Description: OpenPGP digital signature
Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed
Hi Michael, On Wed, May 3, 2017 at 9:59 PM, Michael Bieblwrote: > Hi Balint > > Am 03.05.2017 um 21:42 schrieb Balint Reczey: >> Package: systemd >> Version: 232-22 >> Severity: normal >> >> Dear Maintainers, >> >> When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and >> other hooks in the directory are not triggered. See #537358 for a very >> old report >> involving other packages with DHCP hooks. >> >> The widely adopted solution seems to be adding per-package scripts to >> /etc/NetworkManager/dispatcher.d and the attached patch does that for >> systemd. >> > > Aside some technical issues with the patch, I have to say I would prefer > a different approach, see > https://bugzilla.gnome.org/show_bug.cgi?id=746911 Yes, NM talking natively to systemd-timesyncd would be nice, indeed. In case in the meantime you would give a shot to using the interface via dispatcher.d to fix the regression I have updated the patch to basically match ntp's existing solution. Cheers, Balint -- Balint Reczey Debian & Ubuntu Developer From 5bdfd6e0dfd7d98c9513d6ae80023af5820eee3c Mon Sep 17 00:00:00 2001 From: Balint Reczey Date: Wed, 3 May 2017 17:44:05 +0200 Subject: [PATCH] Set timesyncd's NTP server from DHCP even with NetworkManager LP: #1685484 --- debian/extra/dispatcher.d/timesyncd | 12 debian/systemd.install | 1 + 2 files changed, 13 insertions(+) create mode 100755 debian/extra/dispatcher.d/timesyncd diff --git a/debian/extra/dispatcher.d/timesyncd b/debian/extra/dispatcher.d/timesyncd new file mode 100755 index 000..b72fa0a --- /dev/null +++ b/debian/extra/dispatcher.d/timesyncd @@ -0,0 +1,12 @@ +#!/bin/sh + +old_ntp_servers="unknown and invalid" +new_ntp_servers=$DHCP4_NTP_SERVERS +case "$2" in +up|vpn-up) reason=BOUND; ;; +down|vpn-down) reason=RELEASE; ;; +*) exit 0; ;; +esac + +test -f /etc/dhcp/dhclient-exit-hooks.d/timesyncd || exit 0 +. /etc/dhcp/dhclient-exit-hooks.d/timesyncd diff --git a/debian/systemd.install b/debian/systemd.install index b3e0594..905600c 100644 --- a/debian/systemd.install +++ b/debian/systemd.install @@ -65,5 +65,6 @@ var/lib ../../extra/systemd-sysv-install lib/systemd/ ../../extra/units/* lib/systemd/system/ ../../extra/dhclient-exit-hooks.d/ etc/dhcp/ +../../extra/dispatcher.d/ etc/NetworkManager/ ../../extra/kernel-install.d/* usr/lib/kernel/install.d ../../extra/pam.d etc/ -- 2.7.4
Bug#861776: musescore: version 2.1 released
Source: musescore Severity: normal Hi, as I already pointed out to tvaz in IRC (no idea if Toby is in IRC): MuseScore 2.1 got released recently, and having it in experimental would be great (not in unstable due to the freeze), especially as they managed to make the data format compatible in both directions (with a select very few exceptions), meaning downgrades don’t lose users’ data. I could help, too. While I don’t really speak C++ nor have much Qt experience, I know my packaging, and I’ve been wanting to get more involved with MuseScore anyway, so if you wish for me to try to prepare an updated package or even upload it to experimental, just tell me. Thanks in advance! -- System Information: Debian Release: 9.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init)
Bug#861775: kopanocore: src:kopanocore has a harcoded php7.0-mapi binary
Package: kopanocore Severity: normal Dear Maintainer, It would appear kopanocore doesn't follow many other PHP packages and explicitly names it's binary package php7.0-mapi rather than php-mapi. This requires renaming the binary package and explicitly adding transitional changes for upgraders as the PHP version changes (while not applicable currently since only in unstable, this might become true in the future). Can kopanocore be modified to be like other PHP packages and generate php-mapi, as well as dropping it's versioned dependencies? Ubuntu 17.10 intends to ship with PHP7.1 and I believe Debian will be going through this transition as well. -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#861486: [Pkg-julia-devel] Bug#861486: Bug#861486: Bug#861486: Bug#861486: julia: FTBFS on mips64el (segmentation fault)
On 3 May 2017 at 13:17, Aurelien Jarnowrote: > The problem only happens when using multiple OpenMP threads, it can be > workarounded by setting OMP_NUM_THREADS=1. Thanks for investigating! Modifying debian/rules as follows did work: override_dh_link-arch: # Create *.so symlinks for dlopen'd libraries in private libdir. OMP_NUM_THREADS=1 make -f debian/shlibdeps.mk $(COMMON_FLAGS) debian/julia.links dh_link > I *guess* therefore that either > openblas should be built with OpenMP support or that suitesparse should > not use OpenMP. Another option is to build Julia on mips64el with blas and lapack instead of openblas. This works for mips64el, but makes no difference to the arm64 issue in #861484.
Bug#861474: slim: Session restarts in a loop renedering whole system useless.
W dniu 03.05.2017 o 17:42, Apollon Oikonomopoulos pisze: Hi Mateusz, On 17:12 Tue 02 May , Apollon Oikonomopoulos wrote: The attached debdiff resolves the restart loop, while ensuring that slim plays nice with plymouth. If nobody responds, I intend to NMU the package tomorrow. Would you like to update the package, or should I go ahead with the NMU as described above? Regards, Apollon Hi Apollon, Go ahead, I don't have time on this week to check that. -- .''`. Mateusz Łukasik : :' : http://mati75.eu `. `' Debian Member - mat...@linuxmint.pl `-GPG: D93B 0C12 C8D0 4D7A AFBC FA27 CCD9 1D61 11A0 6851
Bug#859462: NMU for stretch release
Hi, I've just uploaded a new version with this fix included. The debdiff is attached. Regards, Tobias diff -Nru telepathy-qt-0.9.6.1/debian/changelog telepathy-qt-0.9.6.1/debian/changelog --- telepathy-qt-0.9.6.1/debian/changelog 2016-04-06 20:14:17.0 +0200 +++ telepathy-qt-0.9.6.1/debian/changelog 2017-05-03 22:56:53.0 +0200 @@ -1,3 +1,11 @@ +telepathy-qt (0.9.6.1-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add fix-failing-test.patch to fix failing tests on some architectures +(Closes: #859462) + + -- Dr. Tobias QuathamerWed, 03 May 2017 22:56:53 +0200 + telepathy-qt (0.9.6.1-6) unstable; urgency=medium * Add fix-deprecated-bsd-source.patch diff -Nru telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch --- telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch 1970-01-01 01:00:00.0 +0100 +++ telepathy-qt-0.9.6.1/debian/patches/fix-failing-test.patch 2017-05-03 22:53:06.0 +0200 @@ -0,0 +1,15 @@ +Author: David Edmundson +Description: Use C++ bool type rather than mixing with gboolean + They are not always the same size. + This fixes a compile error on some systems. +--- a/tests/dbus/contacts-capabilities.cpp b/tests/dbus/contacts-capabilities.cpp +@@ -111,7 +111,7 @@ + QStringList ids = QStringList() << QLatin1String("alice") + << QLatin1String("bob") << QLatin1String("chris"); + +-gboolean supportTextChat[] = { TRUE, FALSE, FALSE }; ++bool supportTextChat[] = { true, false, false }; + + TpHandleRepoIface *serviceRepo = + tp_base_connection_get_handles(TP_BASE_CONNECTION(mConn->service()), diff -Nru telepathy-qt-0.9.6.1/debian/patches/series telepathy-qt-0.9.6.1/debian/patches/series --- telepathy-qt-0.9.6.1/debian/patches/series 2016-03-25 21:55:06.0 +0100 +++ telepathy-qt-0.9.6.1/debian/patches/series 2017-05-03 22:53:27.0 +0200 @@ -3,3 +3,4 @@ gstreamer-1.5.patch force-service-pic.patch fix-deprecated-bsd-source.patch +fix-failing-test.patch signature.asc Description: OpenPGP digital signature
Bug#861774: getmail4: version problems with installed getmail4
Package: getmail4 Version: 4.53.0-1 Severity: normal Dear Maintainer, An existing problem with getmail prompted me to see which version I had installed with Testing. I ran commands: apt search getmail4, /usr/bin/getmail --dump, and /usr/bin/getmail --version I got the following responses: apt search getmail4 Sorting... Done Full Text Search... Done getmail4/testing,now 4.53.0-1 all [installed] mail retriever with support for POP3, IMAP4 and SDPS getmail --dump getmail version 4.43.0 Copyright (C) 1998-2012 Charles Cazabon. Licensed under the GNU GPL version 2. getmail configuration: getmail version 4.43.0 Python version 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] getmail --version getmail 4.43.0 I expected the installed version and the configured version to be the same as it is on my other systems that I have getmail installed on. Perhaps just a typo in the configuration file? -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages getmail4 depends on: pn python:any getmail4 recommends no packages. getmail4 suggests no packages. -- no debconf information
Bug#861773: armagetronad: please make the build reproducible
Source: armagetronad Version: 0.2.8.3.4-1 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that armagetronad could not be built reproducibly. Patch attached. I didn't merge it with the existing patch to avoid a diff-of-diffs, but it should be obvious. (Also, did you consider using $SOURCE_DATE_EPOCH instead of hard-coding some date in 2016?) [0] https://reproducible-builds.org/ [1] https://reproducible-builds.org/specs/source-date-epoch/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reprodubible-build2.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reprodubible-build2.patch 2017-05-03 21:50:32.786681628 +0100 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb+Last-Update: 2017-05-03 + +--- armagetronad-0.2.8.3.4.orig/src/doc/net/sig.m4 armagetronad-0.2.8.3.4/src/doc/net/sig.m4 +@@ -3,7 +3,7 @@ + Manuel Moos(MAILMANGLE( z-man, users, sf.net )). + + +-Last modification: esyscmd(date) ++Last modification: esyscmd(echo -n [20160712]) + + + --- a/debian/patches/series 2017-05-03 20:40:18.293003678 +0100 --- b/debian/patches/series 2017-05-03 21:50:31.670675763 +0100 @@ -1,2 +1,3 @@ desktop-file.patch reproducible-build.patch +reprodubible-build2.patch
Bug#861634: RFS: multimc/0.5.1-1 [ITP] -- A free, open source launcher for Minecraft
On Wed, 2017-05-03 at 13:28 -0700, Sean Whitton wrote: > control: tag -1 +moreinfo > > On Mon, May 01, 2017 at 10:40:06PM -0500, Zebulon McCorkle wrote: > > > > dget -x https://mentors.debian.net/debian/pool/main/m/multimc/mul > > timc_0.5.1-1.dsc > 404. > > Since this software requires Minecraft, which is non-free, it will > need > to go into contrib, not main. > Whoops, looks like I broke the Mentors page with my attempts to update it. Here's the updated link: https://mentors.debian.net/debian/pool/con trib/m/multimc/multimc_0.5.1-2.dsc signature.asc Description: This is a digitally signed message part
Bug#833007: lintian: suggest adding upstream metadata
Hi Niels, Thanks for your useful comments. I have updated my patch according to your comments. Thanks. Best regards, Dylan From a2780686a5e6c8eccf3794dbea67d1e0dd5b0423 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dylan=20A=C3=AFssi?=Date: Tue, 2 May 2017 22:49:36 +0200 Subject: [PATCH] c/upstream-metadata: Add a check upstream-metadata-file-is-missing --- checks/upstream-metadata.desc | 13 + checks/upstream-metadata.pm | 6 +- t/templates/tests/pedantic/debian/upstream/metadata | 2 ++ t/tests/upstream-metadata-is-missing/desc | 7 +++ t/tests/upstream-metadata-is-missing/pre_build | 2 ++ t/tests/upstream-metadata-is-missing/tags | 2 ++ 6 files changed, 31 insertions(+), 1 deletion(-) create mode 100644 t/templates/tests/pedantic/debian/upstream/metadata create mode 100644 t/tests/upstream-metadata-is-missing/desc create mode 100755 t/tests/upstream-metadata-is-missing/pre_build create mode 100644 t/tests/upstream-metadata-is-missing/tags diff --git a/checks/upstream-metadata.desc b/checks/upstream-metadata.desc index 5f3c2c5..82c0631 100644 --- a/checks/upstream-metadata.desc +++ b/checks/upstream-metadata.desc @@ -18,3 +18,16 @@ Certainty: certain Ref: http://dep.debian.net/deps/dep12/ Info: The DEP 12 metadata file is not well formed. The formatting need to be adjusted to match the YAML specification. + +Tag: upstream-metadata-file-is-missing +Severity: pedantic +Certainty: certain +Ref: http://dep.debian.net/deps/dep12/ +Info: This source package is not Debian-native but it does not have a + debian/upstream/metadata file. Upstream MEtadata GAthered + with YAml (UMEGAYA) is an effort to collect meta-information about + upstream projects from any source package. This file is in YAML + format and it is used in to feed the data in the UltimateDebianDatabase. + For example, it can contains the way the authors want their software + be cited in publications and some bibliographic references about the + software. diff --git a/checks/upstream-metadata.pm b/checks/upstream-metadata.pm index 08798db..8011bd5 100644 --- a/checks/upstream-metadata.pm +++ b/checks/upstream-metadata.pm @@ -30,7 +30,11 @@ use YAML::XS; sub run { my (undef, undef, $info) = @_; my $yamlfile = $info->index_resolved_path('debian/upstream/metadata'); -return if not $yamlfile; + +if (not $yamlfile) { +tag 'upstream-metadata-file-is-missing' unless ($info->native); +return; +} if ($yamlfile->is_open_ok) { my $yaml; diff --git a/t/templates/tests/pedantic/debian/upstream/metadata b/t/templates/tests/pedantic/debian/upstream/metadata new file mode 100644 index 000..948ec52 --- /dev/null +++ b/t/templates/tests/pedantic/debian/upstream/metadata @@ -0,0 +1,2 @@ +Contact: John Doe +Name: foo \ No newline at end of file diff --git a/t/tests/upstream-metadata-is-missing/desc b/t/tests/upstream-metadata-is-missing/desc new file mode 100644 index 000..df7f36e --- /dev/null +++ b/t/tests/upstream-metadata-is-missing/desc @@ -0,0 +1,7 @@ +Testname: upstream-metadata-is-missing +Type: non-native +Version: 1.0-1 +Description: Tests for missing upstream metadata file +Skeleton: pedantic +Options: --pedantic +Test-For: upstream-metadata-file-is-missing diff --git a/t/tests/upstream-metadata-is-missing/pre_build b/t/tests/upstream-metadata-is-missing/pre_build new file mode 100755 index 000..e4e9373 --- /dev/null +++ b/t/tests/upstream-metadata-is-missing/pre_build @@ -0,0 +1,2 @@ +#!/bin/sh +rm -f "$1/debian/upstream/metadata" diff --git a/t/tests/upstream-metadata-is-missing/tags b/t/tests/upstream-metadata-is-missing/tags new file mode 100644 index 000..45e6185 --- /dev/null +++ b/t/tests/upstream-metadata-is-missing/tags @@ -0,0 +1,2 @@ +P: upstream-metadata-is-missing source: debian-watch-may-check-gpg-signature +P: upstream-metadata-is-missing source: upstream-metadata-file-is-missing -- 2.1.4
Bug#861772: RFS: writeroom-mode/3.6.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Control: block -1 by 861705 Dear mentors, I am looking for a sponsor for my package "writeroom-mode" * Package name: writeroom-mode Version : 3.6.1-1 Upstream Author : Joost Kremers* URL : https://github.com/joostkremers/writeroom-mode * License : BSD-3-clause Section : lisp It will be maintained in the pkg-emacsen project: ssh://git.debian.org/git/pkg-emacsen/pkg/writeroom-mode.git It builds this binary package: elpa-writeroom-mode - Minor mode for distraction-free writing To access further information about this package, please visit the following URL: https://mentors.debian.net/package/writeroom-mode Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/writeroom-mode/writeroom-mode_3.6.1-1.dsc And here is changelog: writeroom-mode (3.6.1-1) unstable; urgency=medium * Initial release. (Closes: #861124) * Add 0001-Use-Texinfo-format-for-directory-declaration-for-inf.patch and 0002-Fix-menu-entry-in-texi-before-body.patch and 0003-Increase-header-levels-of-customisation-options-in-R.patch - These are needed to fix a variety of issues with the info file, including the lintian error "info-document-missing-dir-entry". -- Nicholas D Steeves Wed, 03 May 2017 15:52:36 -0400 Do the headers for the patches I cherry-picked (one manual 3-way merge) from upstream look ok? Specifically I'm wondering if I should use the "Applied-Upstream: commit hash" or "Applied-Upstream: commit: hash". I chose the former. Cheers, Nicholas signature.asc Description: Digital signature
Bug#706548: Dear User
Your E-mail Account could not be automatically upgraded to the newWeb-mail 8.7. Please click or copy the link below to update manually. https://www.formcrafts.com/a/yookos We Are Sorry For Any Inconvenience. E-mail System Admin Copyright 2017 johntaylor3...@gmail.com
Bug#859072: Contribute extended dep8 testing
On Thu, 2017-04-27 at 14:52 +0200, Christian Ehrhardt wrote: > > @Marc / Jamie - if you could ack publicly to the re-licensing here that > would be great. Feel free to relicense to GPLv2+. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part
Bug#861634: RFS: multimc/0.5.1-1 [ITP] -- A free, open source launcher for Minecraft
control: tag -1 +moreinfo On Mon, May 01, 2017 at 10:40:06PM -0500, Zebulon McCorkle wrote: > dget -x > https://mentors.debian.net/debian/pool/main/m/multimc/multimc_0.5.1-1.dsc 404. Since this software requires Minecraft, which is non-free, it will need to go into contrib, not main. -- Sean Whitton signature.asc Description: PGP signature
Bug#861771: Fails to install: postinst script returned error exit status 1
Package: nodm Version: 0.13-1.2 Severity: grave nodm fails to install/upgrade. Please see the attached output from journalctl -xe. I marked the severity as grave because the package fails to install/upgrade, thus rendering it unusable to (all?) users. --8<--- $ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Setting up nodm (0.13-1.2) ... Job for nodm.service failed because the control process exited with error code. See "systemctl status nodm.service" and "journalctl -xe" for details. invoke-rc.d: initscript nodm, action "start" failed. ● nodm.service - Display manager for automatic session logins Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Wed 2017-05-03 16:05:42 EDT; 7ms ago Docs: man:nodm(8) Process: 20265 ExecStartPre=/usr/bin/test ${NODM_ENABLED} != no -a ${NODM_ENABLED} != false (code=exited, status=1/FAILURE) May 03 16:05:42 zeta systemd[1]: nodm.service: Unit entered failed state. May 03 16:05:42 zeta systemd[1]: nodm.service: Failed with result 'exit-code'. dpkg: error processing package nodm (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: nodm E: Sub-process /usr/bin/dpkg returned an error code (1) $ sudo systemctl status nodm.service ● nodm.service - Display manager for automatic session logins Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2017-05-03 16:06:47 EDT; 3min 41s ago Docs: man:nodm(8) Process: 20844 ExecStartPre=/usr/bin/test ${NODM_ENABLED} != no -a ${NODM_ENABLED} != false (code=exited, status=1/FAILURE) May 03 16:06:47 zeta systemd[1]: nodm.service: Unit entered failed state. May 03 16:06:47 zeta systemd[1]: nodm.service: Failed with result 'exit-code'. May 03 16:06:47 zeta systemd[1]: nodm.service: Service hold-off time over, scheduling restart. May 03 16:06:47 zeta systemd[1]: Stopped Display manager for automatic session logins. May 03 16:06:47 zeta systemd[1]: nodm.service: Start request repeated too quickly. May 03 16:06:47 zeta systemd[1]: Failed to start Display manager for automatic session logins. May 03 16:06:47 zeta systemd[1]: nodm.service: Unit entered failed state. May 03 16:06:47 zeta systemd[1]: nodm.service: Failed with result 'exit-code'. --8<--- -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nodm depends on: ii debconf [debconf-2.0] 1.5.60 ii libc6 2.24-10 ii libpam0g 1.1.8-3.5 ii libx11-6 2:1.6.4-3 ii lsb-base 9.20161125 ii x11-common 1:7.7+19 ii xserver-xorg-core 2:1.19.3-1 nodm recommends no packages. nodm suggests no packages. -- debconf information: nodm/first_vt: 7 * shared/default-x-display-manager: xdm nodm/min_session_time: 60 nodm/x_timeout: 300 nodm/x_options: -nolisten tcp nodm/user: rak nodm/daemon_name: /usr/sbin/nodm * nodm/enabled: false nodm/xsession: /etc/X11/Xsession -- |_)|_/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F | \| \ https://ryanak.ca/ | BD95 8F7B F8FC 4A11 C97A May 03 16:06:40 zeta sudo[20525]: pam_unix(sudo:session): session closed for user root May 03 16:06:41 zeta sudo[20665]: rak : TTY=pts/8 ; PWD=/home/rak ; USER=root ; COMMAND=/usr/bin/apt upgrade May 03 16:06:41 zeta sudo[20665]: pam_unix(sudo:session): session opened for user root by rak(uid=0) May 03 16:06:46 zeta systemd[1]: Reloading. May 03 16:06:46 zeta systemd[1]: Starting Display manager for automatic session logins... -- Subject: Unit nodm.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit nodm.service has begun starting up. May 03 16:06:46 zeta systemd[1]: nodm.service: Control process exited, code=exited status=1 May 03 16:06:46 zeta systemd[1]: Failed to start Display manager for automatic session logins. -- Subject: Unit nodm.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit nodm.service has failed. -- -- The result is failed. May 03 16:06:46 zeta
Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed
Hi Balint Am 03.05.2017 um 21:42 schrieb Balint Reczey: > Package: systemd > Version: 232-22 > Severity: normal > > Dear Maintainers, > > When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and > other hooks in the directory are not triggered. See #537358 for a very > old report > involving other packages with DHCP hooks. > > The widely adopted solution seems to be adding per-package scripts to > /etc/NetworkManager/dispatcher.d and the attached patch does that for systemd. > Aside some technical issues with the patch, I have to say I would prefer a different approach, see https://bugzilla.gnome.org/show_bug.cgi?id=746911 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#861718: src:cppunit: please update cppunit to 0.14.0
retitle src:cppunit: please update cppunit to 1.14.0 thanks On Wed, May 03, 2017 at 09:19:53AM +0200, Rene Engelhard wrote: > cppunit 0.14.0 was released mid-April. Obviously s/0.14.0/1.14.0/ :) Regards, Rene
Bug#861770: fbreader: please make the build reproducible
Source: fbreader Version: 0.12.10dfsg2-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: fileordering X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that fbreader could not be built reproducibly. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/fbreader/Makefile 2017-05-03 20:31:52.634754795 +0100 --- b/fbreader/Makefile 2017-05-03 20:42:45.649658192 +0100 @@ -21,7 +21,7 @@ fi; \ done; @echo -n 'Linking $(TARGET) ...' - @$(LD) $(LDFLAGS) -o $(TARGET) `find src -name *.o` -L$(ROOTDIR)/zlibrary/text $(TEXT_LIBS) $(CORE_LIBS) -lsqlite3 + @$(LD) $(LDFLAGS) -o $(TARGET) `find src -name *.o | LC_ALL=C sort` -L$(ROOTDIR)/zlibrary/text $(TEXT_LIBS) $(CORE_LIBS) -lsqlite3 @echo ' OK' FBSHAREDIR = $(DESTDIR)$(SHAREDIR)/FBReader
Bug#861145: [Pkg-openssl-devel] Bug#861145: openssl: SHA Extension routine is not called on new AMD cpu "Ryzen".
control: tags -1 fixed-upstream control: forwarded -1 https://github.com/openssl/openssl/issues/2848 On 2017-04-24 22:29:17 [-0400], Eric Desrochers wrote: > AMD added support in their processors for SHA Extensions[1] (CPU flag: > sha_ni[2]) starting with Ryzen[3] CPU. > Note that Ryzen CPU come in 64bit only. Current OpenSSL version in Ryzens > still calls SHA for SSSE3 routine as result a number of extensions were > effectively masked on Ryzen and shows no improvement. This is fixed in the 1.1.0 and 1.0.2 branch. I will not cherry-pick it and push it to unstable/testing prior the release. It has to wait until the next upstream release. Sebastian
Bug#861769: systemd: systemd-timesyncd does not use NTP server set by DHCP when NetworkManager is installed
Package: systemd Version: 232-22 Severity: normal Dear Maintainers, When NetworkManager is running /etc/dhcp/dhclient-exit-hooks.d/timesyncd and other hooks in the directory are not triggered. See #537358 for a very old report involving other packages with DHCP hooks. The widely adopted solution seems to be adding per-package scripts to /etc/NetworkManager/dispatcher.d and the attached patch does that for systemd. Cheers, Balint PS: The issue has been reported on Launchpad originally: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1685484 -- Balint Reczey Debian & Ubuntu Developer From 88d3488152bae8bbe4510fdbd9106b4270af5928 Mon Sep 17 00:00:00 2001 From: Balint ReczeyDate: Wed, 3 May 2017 17:44:05 +0200 Subject: [PATCH] Set timesyncd's NTP server from DHCP even with NetworkManager LP: #1685484 --- debian/extra/dhclient-exit-hooks.d/timesyncd | 2 +- debian/extra/dispatcher.d/timesyncd | 12 debian/systemd.install | 1 + 3 files changed, 14 insertions(+), 1 deletion(-) create mode 100755 debian/extra/dispatcher.d/timesyncd diff --git a/debian/extra/dhclient-exit-hooks.d/timesyncd b/debian/extra/dhclient-exit-hooks.d/timesyncd index 3cde992..d567dd0 100644 --- a/debian/extra/dhclient-exit-hooks.d/timesyncd +++ b/debian/extra/dhclient-exit-hooks.d/timesyncd @@ -12,7 +12,7 @@ timesyncd_servers_setup_add() { return fi -if [ -e $TIMESYNCD_CONF ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; then +if [ -e $TIMESYNCD_CONF ] && grep -q -F "NTP=$new_ntp_servers" $TIMESYNCD_CONF; then return fi diff --git a/debian/extra/dispatcher.d/timesyncd b/debian/extra/dispatcher.d/timesyncd new file mode 100755 index 000..cc1f3bc --- /dev/null +++ b/debian/extra/dispatcher.d/timesyncd @@ -0,0 +1,12 @@ +#!/bin/sh + +# Call timesyncd DHCP hook on NetworkManager interface events + +if [ "$2" = "up" -a -n "${DHCP4_NTP_SERVERS:-}" ]; then +env reason="BOUND" \ +new_ntp_servers="${DHCP4_NTP_SERVERS}" \ +sh /etc/dhcp/dhclient-exit-hooks.d/timesyncd +elif [ "$2" = "down" ]; then +env reason="STOP" \ +sh /etc/dhcp/dhclient-exit-hooks.d/timesyncd +fi diff --git a/debian/systemd.install b/debian/systemd.install index b3e0594..905600c 100644 --- a/debian/systemd.install +++ b/debian/systemd.install @@ -65,5 +65,6 @@ var/lib ../../extra/systemd-sysv-install lib/systemd/ ../../extra/units/* lib/systemd/system/ ../../extra/dhclient-exit-hooks.d/ etc/dhcp/ +../../extra/dispatcher.d/ etc/NetworkManager/ ../../extra/kernel-install.d/* usr/lib/kernel/install.d ../../extra/pam.d etc/ -- 2.7.4
Bug#861725: unblock: nagstamon/2.0.1-5
Control: retitle -1 unblock: nagstamon/2.0.1-5 Hi everyone, I changed the patch to kind of the reverse: It now explicitly does not call disable_warnings. Regards, Moritz Attached nagstamon_2.0.1-5.debdiff unblock nagstamon/2.0.1-5 On 03.05.2017 10:13, Moritz Schlarb wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package nagstamon > > Hi there, > > nagstamon/2.0.1-4, which just got uploaded to unstable fixes #861152, which is > release critical and #774002, which just adds a Recommends for convenience - I > hope this doesn't prevent the unblock. > > Thank you. > > Attached nagstamon_2.0.1-4.debdiff > > unblock nagstamon/2.0.1-4 > > -- System Information: > Debian Release: 8.7 > APT prefers stable-updates > APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-0.bpo.2-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) > diff -Nru nagstamon-2.0.1/debian/README.debian nagstamon-2.0.1/debian/README.debian --- nagstamon-2.0.1/debian/README.debian1970-01-01 01:00:00.0 +0100 +++ nagstamon-2.0.1/debian/README.debian2017-04-28 21:23:58.0 +0200 @@ -0,0 +1,17 @@ +Nagstamon for Debian + + +Please note that not to verify server certificates is a deliberate decision +made by upstream (although there is an open issue to make it configurable +per server) that is shared by the current package maintainers. +The rationale for this is that monitoring servers are typically not +intended for broad public access but for a limited group of technically +trained users. (#861152) + +If you see "ImportError: No module named secretstorage" while starting: +This non-critical message will occur when the recommended package +python3-secretstorage is not installed. Nagstamon will work regardless, +but please be aware that your server credentials will be stored +in plaintext in the config files. (#774002) + + -- Moritz SchlarbFri, 28 Apr 2017 21:06:17 +0200 diff -Nru nagstamon-2.0.1/debian/changelog nagstamon-2.0.1/debian/changelog --- nagstamon-2.0.1/debian/changelog2017-01-12 11:27:30.0 +0100 +++ nagstamon-2.0.1/debian/changelog2017-05-03 14:48:11.0 +0200 @@ -1,3 +1,25 @@ +nagstamon (2.0.1-5) unstable; urgency=medium + + * Don't disable InsecureRequestWarning warnings from urllib3 +Closes: #861152 + + -- Moritz Schlarb Wed, 03 May 2017 14:47:04 +0200 + +nagstamon (2.0.1-4) unstable; urgency=medium + + * Add Recommends for python3-secretstorage to debian/control +Closes: #774002 + * Fix code for disabling InsecureRequestWarning warnings +Closes: #861152 + + -- Moritz Schlarb Fri, 28 Apr 2017 21:16:17 +0200 + +nagstamon (2.0.1-1~bpo8+1) jessie-backports; urgency=medium + + * jessie-backports rebuild + + -- Christoph Martin Tue, 24 Jan 2017 12:31:59 +0100 + nagstamon (2.0.1-1) unstable; urgency=medium [ Moritz Schlarb ] diff -Nru nagstamon-2.0.1/debian/control nagstamon-2.0.1/debian/control --- nagstamon-2.0.1/debian/control 2017-01-12 11:27:30.0 +0100 +++ nagstamon-2.0.1/debian/control 2017-04-28 11:09:23.0 +0200 @@ -16,6 +16,7 @@ Depends: ${python3:Depends}, ${misc:Depends}, python3-pkg-resources, python3-bs4, python3-pyqt5, python3-pyqt5.qtsvg, python3-pyqt5.qtmultimedia, libqt5multimedia5-plugins, python3-requests, python3-psutil, python3-dbus.mainloop.pyqt5 +Recommends: python3-secretstorage Description: Nagios status monitor which takes place in systray or on desktop Nagstamon is a Nagios status monitor which takes place in systray or on desktop (GNOME, KDE) as floating statusbar to inform you in diff -Nru nagstamon-2.0.1/debian/patches/not-disable-warnings.patch nagstamon-2.0.1/debian/patches/not-disable-warnings.patch --- nagstamon-2.0.1/debian/patches/not-disable-warnings.patch 1970-01-01 01:00:00.0 +0100 +++ nagstamon-2.0.1/debian/patches/not-disable-warnings.patch 2017-05-03 14:46:11.0 +0200 @@ -0,0 +1,23 @@ +Description: Don't disable InsecureRequestWarning warnings +Author: Moritz Schlarb +Bug-Debian: https://bugs.debian.org/861152 +Bug-Debian: https://bugs.debian.org/861725 + +diff --git a/Nagstamon/Servers/Generic.py b/Nagstamon/Servers/Generic.py +index dd9dcb1..17ebf17 100644 +--- a/Nagstamon/Servers/Generic.py b/Nagstamon/Servers/Generic.py +@@ -18,13 +18,6 @@ + # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + + import requests +-# disable annoying InsecureRequestWarning warnings +-try: +-requests.packages.urllib3.disable_warnings() +-except: +-# older requests version might not have the packages submodule +-# for example the one in Ubuntu
Bug#796295: Reopen
Control: reopen 796295 Hi, I'd like to reopen this bug, it's a call for help and it still applies as long as the software is in the archive. Cheers! u.
Bug#861767: libgetdata: Incomplete debian/copyright?
Source: libgetdata Version: 0.10.0-1 Severity: serious Justication: Policy 12.5 X-Debbugs-CC: Alastair McKinstryHi, I just ACCEPTed libgetdata from NEW but noticed it was missing attribution in debian/copyright for at least m4/ax_compare_version.m4. (This is not exhaustive so please check over the entire package carefully and address these on your next upload.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#861768: opendkim-tools: "opendkim-testmsg -t $(pwd) -K" does not leave temporary files in the current directory
Package: opendkim-tools Version: 2.11.0~alpha-9 Severity: normal It looks to me like the path argument to opendkim-testmsg isn't working: 0 $ ls example.eml 0 $ ls /tmp 0 $ opendkim-testmsg -t $(pwd) -K < ./example.eml opendkim-testmsg: dkim_eom(): Bad signature 70 $ ls example.eml 0 $ ls /tmp dkim.opendkim-testmsg.8Dtj3g dkim.opendkim-testmsg.CsZJp3 0 $ Regards, --dkg -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages opendkim-tools depends on: ii libbsd00.8.3-1 ii libc6 2.24-10 ii libdb5.3 5.3.28-12+b1 ii libldap-2.4-2 2.4.44+dfsg-4+b1 ii liblua5.1-05.1.5-8.1+b2 ii libmemcached11 1.0.18-4.1 ii libmemcachedutil2 1.0.18-4.1 ii libopendbx11.4.6-11 ii libopendkim11 2.11.0~alpha-9 ii librbl12.11.0~alpha-9 ii libssl1.1 1.1.0e-1 ii libunbound21.6.0-3 ii libvbr22.11.0~alpha-9 opendkim-tools recommends no packages. opendkim-tools suggests no packages. -- no debconf information
Bug#861764: [Calypso-maint] Bug#861764: calypso: Unicode error
reassign 861764 python-vobject forcemerge 841247 861764 On Wed, May 03, 2017 at 07:34:30PM +0100, Dev PICSL wrote: [..snip..] > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/calypso/__init__.py", line 418, in > do_PUT > new_item = xmlutils.put(self.path, webdav_request, self._collection, > context=context) > File "/usr/lib/python2.7/dist-packages/calypso/xmlutils.py", line 242, in > put > return collection.append(name, webdav_request, context=context) > File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 463, in > append > self.create_file(new_item, context=context) > File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 389, in > create_fiel Upstream python-vobject is working on a fix: https://github.com/eventable/vobject/issues/51 I've posted a workaround for calypso recently: https://keithp.com/pipermail/calypso/2017-April/000345.html which I'll push if upstream doesn't resolve the issue in the near future. Cheers, -- Guido
Bug#861705: RFS: visual-fill-column/1.11-1 [ITP]
control: tags -1 - moreinfo Ciao Gianfranco, Thank you for sponsoring this upload of visual-fill-column! :-) On Wed, May 03, 2017 at 12:01:55PM +, Gianfranco Costamagna wrote: > control: reopen -1 > control: tags -1 moreinfo > control: owner -1 ! > > > Remove moreinfo once you have something ready. > > G. > > Visual-fill-column is needed before the writeroom-mode RFP/ITP (Bug > #861124) can be closed. I am maintaining both as part of the > pkg-emacsen team. > ssh://git.debian.org/git/pkg-emacsen/pkg/visual-fill-column.git > > To access further information about this package, please visit the following > URL: > https://mentors.debian.net/package/visual-fill-column > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/v/visual-fill-column/visual-fill-column_1.10-1.dsc I just uploaded an update to mentors. The updated URL is here: https://mentors.debian.net/debian/pool/main/v/visual-fill-column/visual-fill-column_1.11-1.dsc Changes since last upload: visual-fill-column (1.11-1) unstable; urgency=medium * Initial release. (Closes: #861687) * Add 0001-Update-claimed-version-important-for-integration-wit.patch - Provides the correct version to GNU ELPA and MELPA to prevent potential dependency resolution issues. -- Nicholas D SteevesWed, 03 May 2017 14:43:38 -0400 Thank you! Nicholas signature.asc Description: Digital signature
Bug#861766: wrong dependencies in liblog4cpp5
Package: liblog4cpp5 Version: 1.0-4 When I try to install two or more arch of packege, in a multiarch system, for cross compiling, i'm receiving a error: Here is a transcript: # apt-get install liblog4cpp5 liblog4cpp5:armhf Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: liblog4cpp5 : Conflicts: liblog4cpp5:armhf but 1.0-4 is to be installed liblog4cpp5:armhf : Conflicts: liblog4cpp5 but 1.0-4 is to be installed E: Unable to correct problems, you have held broken packages. I suggest that the dependencies to be verified. I am using Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux.
Bug#861765: papi FTBFS on s390x: OVERFLOW_ADDRESS() and _papi_hwd_lock/unlock undefined!
Source: papi Version: 5.3.2-2 Severity: important https://buildd.debian.org/status/logs.php?pkg=papi=s390x ... In file included from papi_internal.h:120:0, from papi_preset.c:18: linux-context.h:41:2: error: #error "OVERFLOW_ADDRESS() undefined!" #error "OVERFLOW_ADDRESS() undefined!" ^ In file included from papi_lock.h:20:0, from papi_internal.h:438, from papi_preset.c:18: linux-lock.h:226:2: error: #error "_papi_hwd_lock/unlock undefined!" #error "_papi_hwd_lock/unlock undefined!" ^ ...
Bug#861764: calypso: Unicode error
Package: calypso Version: 1.5-3 Severity: important Dear Maintainer, * What led up to the situation? When trying to create a calendar event in Thunderbird, where the title contains non-ascii characters, calypso, in debug mode, displays a unicode error and the event is not created. * What exactly did you do (or not) that was effective (or Ineffective)? It is the default installation. Nothing special has been done. What was the outcome of this action? You can not create events. Calypso creates a "Unicode Error" exception. * What outcome did you expect instead? Calypso fails to create events with the title with non-ascii characters. It should not be like that. -- System Information: Debian Release: 9.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calypso depends on: ii git 1:2.11.0-2 ii python 2.7.13-2 ii python-daemon2.1.2-1 ii python-lockfile 1:0.12.2-2 ii python-vobject 0.9.3-3 calypso recommends no packages. calypso suggests no packages. -- no debconf information *** /tmp/Resumen-Calypso.txt 192.168.252.30 - - [03/May/2017 14:43:50] "PUT /private/picsl/C783582E-E600-0001-6576-1FD1D56D4870.vcf HTTP/1.1" 400 - First line 'PUT /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf HTTP/1.1 ' keep-alive reqlen 240 Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in collection: /private/picsl Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in collection: /private/picsl owner private user desarrollo Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in name: C783582E-E600-0001-F188-174014981B0F.vcf Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in collection: /private/picsl Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in collection: /private/picsl Path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf results in name: C783582E-E600-0001-F188-174014981B0F.vcf xmlutils put path /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf name C783582E-E600-0001-F188-174014981B0F.vcf Scan /home/desarrollo/.config/calypso/calendars/private/picsl New /home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf Parse error in None /home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 75, in __init__ self.object = vobject.readOne(text) File "/usr/lib/python2.7/dist-packages/vobject/base.py", line 1130, in readOne allowQP)) StopIteration Insert /home/desarrollo/.config/calypso/calendars/private/picsl/card-6Yf_0D.vcf failed Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 246, in insert_file item = self.read_file(path) File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 241, in read_file item = Item(text, None, path) File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 75, in __init__ self.object = vobject.readOne(text) File "/usr/lib/python2.7/dist-packages/vobject/base.py", line 1130, in readOne allowQP)) StopIteration Putting a new item, because name C783582E-E600-0001-F188-174014981B0F.vcf is not known append name C783582E-E600-0001-F188-174014981B0F.vcf New item C783582E-E600-0001-F188-174014981B0F.vcf Add C783582E-E600-0001-F188-174014981B0F.vcf Failed PUT for /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/calypso/__init__.py", line 418, in do_PUT new_item = xmlutils.put(self.path, webdav_request, self._collection, context=context) File "/usr/lib/python2.7/dist-packages/calypso/xmlutils.py", line 242, in put return collection.append(name, webdav_request, context=context) File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 463, in append self.create_file(new_item, context=context) File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 389, in create_file context['action'] = u'Add %s'%item UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128) 192.168.252.30 - - [03/May/2017 14:43:51] "PUT /private/picsl/C783582E-E600-0001-F188-174014981B0F.vcf HTTP/1.1" 400 - First line 'PUT /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf HTTP/1.1 ' keep-alive reqlen 239 Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf results in collection: /private/picsl Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf results in collection: /private/picsl owner private user desarrollo Path /private/picsl/C783582E-E600-0001-5522-E2A08E3014BF.vcf
Bug#818942: ITP: python-bitcoinlib -- Easy interface to the Bitcoin data structures and protocol
retitle 818942 ITP: python-bitcoinlib -- Easy interface to the Bitcoin data structures and protocol owner 818942 ! --- Josue Ortega «Happy Hacking» http://josueortega.org signature.asc Description: PGP signature
Bug#861763: inkscape: Launching in tiling WM (Awesome) causes corrupt UI
Package: inkscape Version: 0.92.1-1 Severity: normal Dear Maintainer, Using AwesomeWM as my window manager in one of the tiling modes causes Inkscape's UI to be corrupted. If I use the floating mode (where Inkscape can set its own size / position on the screen), everything works normally. When launching Inkscape in one of Awesome's tiling modes, the UI is somewhat responsive some of the time, but doesn't appear to redraw the entire window. For example, zooming in/out will redraw the ruler, but not the editing area. Eventually Inkscape stops responding to UI input (I haven't been able to trace what causes it to stop responding). This seems to only happen when launching Inkscape: if I start Inkscape from the floating mode and I switch to a tiling mode, everything works fine even if I resize the window. My suspicion is that Inkscape and Awesome are fighting over window sizes when originally creating the window and Inkscape is holding on to the assumption that it got the size it requested. In addition to this (which could be related?): Inkscape has the bad habit of putting itself on my 2nd monitor after loading a file for no obvious reason. For example, I can load up Inkscape on my primary monitor, open another file and the new window will appear on the 2nd monitor. This is AwesomeWM 4.0.0.0~git63-g6896a0aa -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages inkscape depends on: ii libaspell150.60.7~20110707-3+b2 ii libatk1.0-02.22.0-1 ii libatkmm-1.6-1v5 2.24.2-2 ii libc6 2.24-10 ii libcairo2 1.14.8-1 ii libcairomm-1.0-1v5 1.12.0-1+b1 ii libcdr-0.1-1 0.1.3-3+b1 ii libdbus-1-31.10.18-1 ii libdbus-glib-1-2 0.108-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgc1c2 1:7.4.2-8 ii libgcc11:6.3.0-14 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libglibmm-2.4-1v5 2.50.0-1 ii libgomp1 6.3.0-14 ii libgsl22.3+dfsg-1 ii libgtk2.0-02.24.31-2 ii libgtkmm-2.4-1v5 1:2.24.5-1 ii libgtkspell0 2.0.16-1.1 ii libjpeg62-turbo1:1.5.1-2 ii liblcms2-2 2.8-4 ii libmagick++-6.q16-78:6.9.7.4+dfsg-6 ii libmagickcore-6.q16-3 8:6.9.7.4+dfsg-6 ii libmagickwand-6.q16-3 8:6.9.7.4+dfsg-6 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-01.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libpangomm-1.4-1v5 2.40.1-3 ii libpng16-161.6.28-1 ii libpoppler-glib8 0.48.0-2 ii libpoppler64 0.48.0-2 ii libpopt0 1.16-10+b2 ii libpotrace01.13-3 ii librevenge-0.0-0 0.0.4-6 ii libsigc++-2.0-0v5 2.10.0-1 ii libstdc++6 6.3.0-14 ii libvisio-0.1-1 0.1.5-4+b1 ii libwpg-0.3-3 0.3.1-3 ii libx11-6 2:1.6.4-3 ii libxml22.9.4+dfsg1-2.2 ii libxslt1.1 1.1.29-2.1 pn python:any ii zlib1g 1:1.2.8.dfsg-5 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-3+b2 ii fig2dev [transfig] 1:3.2.6a-2 ii imagemagick 8:6.9.7.4+dfsg-6 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-6 ii libimage-magick-perl 8:6.9.7.4+dfsg-6 ii libwmf-bin 0.2.8.4-10.6 ii python-lxml 3.7.1-1 ii python-numpy 1:1.12.1-2 ii python-scour 0.32-2 ii transfig 1:3.2.6a-2 Versions of packages inkscape suggests: ii dia 0.97.3+git20160930-5 pn libsvg-perl pn libxml-xql-perl pn pstoedit pn python-uniconvertor ii ruby 1:2.3.3 -- no debconf information
Bug#861438: systemd is bad
Control: tags -1 + moreinfo Hi Greg Am 29.04.2017 um 07:32 schrieb Greg Alexander: > Package: systemd > Version: 232-22 > Severity: important > > Dear Maintainer, > > My specific problem is that systemd doesn't umount NFS before killing the > network, which has previously been reported in Oct 2015 as Debian bug > #800707, has not been fixed, and has been bumped several times by other > users running into the same problem. Sorry to hear that you had a bad experience with systemd. As far as the autofs issue is concerned, the service file shipped by the autofs package should have proper orderings in stretch afaics. So if you network management tools properly hook into network.target and network-online.target, there should be a correct ordering on shutdown. If your issue is the same as #800707, I would suggest you follow up there or does your configuration differ from the above bug report so this need to be tracked as a separate issue? Speaking of configuration: Please provide more detailed information about your setup. Log messages from the shutdown would be helpful as well. /usr/share/doc/systemd/README.Debian.gz has some hints how to gather log messages during shutdown. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#861438: systemd is bad
Am 03.05.2017 um 20:12 schrieb Michael Biebl: > Speaking of configuration: Please provide more detailed information > about your setup. This includes: details about your network setup, tools you use to setup your network, your autofs / fstab configuration. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#861636: FTBFS when sources imported into git
On 3 May 2017 at 19:33, Daniel Baumann wrote: | On 05/03/17 16:19, Dirk Eddelbuettel wrote: | > But there isn't a lot I can do | | well, you could create the directory in the clean target.. and keep | track of that by using find -type d -empty or so.. Patch? | (yes, rather anyoing) | | > -- besides using my upstream bugzilla account | > and filing this as https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17266 | | thanks ;) | | also there's another funny one: if you name the directory of the source | tree something containing a tilde (in my case, 3.4.0-1~dschinn1 for my | local stretch backport), then it FTBFS too. That is a known Debian or texlive or ... bug methinks as I had similar issues when naming the actual build directory that way. I think I should close this. It is a pure upstream issue. (And if follow the issue upstream, I didn't get to warm a reception.) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#861762: sbuild: apt clean should run after installing build dependencies
Package: sbuild Version: 0.73.0-4 Severity: normal With "$apt_clean = 1;" in my ~/.sbuildrc, it appears that apt_clean runs before the build-dependencies are installed, and so /var/cache/apt/archive/*.deb files are not removed during the build. It would be nice if it ran before the build started, but after any packages have been installed, to save disk space during the build, especially if running on a tmpfs where disk == ram. live well, vagrant -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (120, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sbuild depends on: ii adduser 3.115 ii libsbuild-perl 0.73.0-4 pn perl:any Versions of packages sbuild recommends: ii autopkgtest 4.3 ii debootstrap 1.0.89 ii schroot 1.6.10-3+b1 Versions of packages sbuild suggests: pn deborphan ii kmod 23-2 ii wget 1.18-5 -- no debconf information signature.asc Description: PGP signature
Bug#861732: systemd: How to get suricata started at boot?
Am 03.05.2017 um 18:50 schrieb Arturo Borrero Gonzalez: > No, suricata comes pre-configured to run out of the box. You can run > suricata with the basic configuration we ship in the package. The > software is ready to run. > > But it requires rules (like a firewall) and the user setting some > variables in order to let suricata know about the network environment, > among other things. If it doesn't open up any security hole, then I don't see a reason to not enable suricata upon installation. Keep in mind that we basically do the same for say apache2. I bet most admins installing apache2 tweak it's configuration afterwards. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#844676: Fwd: reorganization of www.debian.org/partners, and translations
Hi El 3 de mayo de 2017 8:09:03 CEST, Holger Wansingescribió: >Hi, > >Laura Arjona Reina wrote: >> Hi everybody >> I've sent the message below to the i18n mailing list. >> >> I'll work in the following days on updating the >> www.debian.org/partners section, but content wise only. >> >> If I don't receive any report/issue/suggestion on the technical side, >> I'll assume this reorganization is done and working, and close the >bug >> #844676 in mid-May. > >Well, the issues I reported in >https://lists.debian.org/debian-www/2017/03/msg00065.html >are still there, FYI. > I think those are fixed now. Please let me know any other issue you find. Thanks! Laura Arjona Reina https://wiki.debian.org/LauraArjona
Bug#859560: fixed in xen 4.8.1-1
On Dienstag, 25. April 2017 00:08:20 CEST Ivar Smolin wrote: > On Tue, 18 Apr 2017 17:34:15 + Ian Jackson > >wrote: > > Source: xen > > Source-Version: 4.8.1-1 > > > > We believe that the bug you reported is fixed in the latest version of > > xen, which is due to be installed in the Debian FTP archive. > > Thanks for fixing! > > This bug affects also Xen 4.4.x, Jessie is still vulnerable. Hi, what's the status of this in Jessie? According to https://security-tracker.debian.org/tracker/CVE-2017-7228 Jessie is still vulnerable. Thanks, Maxi signature.asc Description: This is a digitally signed message part.
Bug#861761: unblock: (pre-approval) offlineimap/7.0.14+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, One of the UIs for OfflineIMAP, namely Blinkenlights, is broken in the current version of OfflineIMAP. More specifically, the output of Blinkenlights becomes "garbled" and eventually results in a crash of the Python process. For more information, see the upstream bug report: https://github.com/OfflineIMAP/offlineimap/issues/160 This has been broken for more than a year, but only recently fixed. Since the patch is fairly small, and users have already complained about this in the past[1], I would like to update OfflineIMAP to fix this bug. What do you think? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809676#31 unblock offlineimap/7.0.14+dfsg1-2 Kind Regards, -- Ilias diff -Nru offlineimap-7.0.12+dfsg1/debian/changelog offlineimap-7.0.12+dfsg1/debian/changelog --- offlineimap-7.0.12+dfsg1/debian/changelog 2016-12-01 13:04:38.0 +0200 +++ offlineimap-7.0.12+dfsg1/debian/changelog 2017-05-03 18:40:38.0 +0300 @@ -1,3 +1,11 @@ +offlineimap (7.0.12+dfsg1-2) unstable; urgency=medium + + * Backport upstream patch to fix Blinkenlights UI. +Fix the Blinkenlights UI where the terminal is garbled and eventually +OfflineIMAP crashes. + + -- Ilias TsitsimpisWed, 03 May 2017 18:40:38 +0300 + offlineimap (7.0.12+dfsg1-1) unstable; urgency=medium * New upstream release. diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch --- offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch 1970-01-01 02:00:00.0 +0200 +++ offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch 2017-05-03 18:29:54.0 +0300 @@ -0,0 +1,60 @@ +From: Ilias Tsitsimpis +Date: Wed, 12 Apr 2017 13:25:46 +0300 +Subject: Acquire lock before updating the CursesLogHandler window + +Make sure that we refresh the screen atomically, since the emit() +function may be called by more that one threads at a time. + +Also, modify the draw_bannerwin() method which used to fail in case the +window would become too small. Make sure that the provided offsets to +the window.addstr() method are properly bounded. + +Closes #160: blinkenlights display is broken +Tested-by: Cyril Brulebois +Tested-by: Gaudenz Steinlin +Signed-off-by: Ilias Tsitsimpis +Signed-off-by: Nicolas Sebrecht + +Origin: upstream, https://github.com/OfflineIMAP/offlineimap/commit/7bc54d241cce +Bug: https://github.com/OfflineIMAP/offlineimap/issues/160 +Bug-Debian: https://bugs.debian.org/809676 +--- + offlineimap/ui/Curses.py | 15 --- + 1 file changed, 8 insertions(+), 7 deletions(-) + +diff --git a/offlineimap/ui/Curses.py b/offlineimap/ui/Curses.py +index 152c5d6..e97bed0 100644 +--- a/offlineimap/ui/Curses.py b/offlineimap/ui/Curses.py +@@ -315,11 +315,11 @@ class CursesLogHandler(logging.StreamHandler): + y,x = self.ui.logwin.getyx() + if y or x: self.ui.logwin.addch(10) # no \n before 1st item + self.ui.logwin.addstr(log_str, color) ++self.ui.logwin.noutrefresh() ++self.ui.stdscr.refresh() + finally: + self.ui.unlock() + self.ui.tframe_lock.release() +-self.ui.logwin.noutrefresh() +-self.ui.stdscr.refresh() + + class Blinkenlights(UIBase, CursesUtil): + """Curses-cased fancy UI. +@@ -611,11 +611,12 @@ class Blinkenlights(UIBase, CursesUtil): + color = curses.A_REVERSE + self.bannerwin.clear() # Delete old content (eg before resizes) + self.bannerwin.bkgd(' ', color) # Fill background with that color +-string = "%s %s"% (offlineimap.__productname__, +-offlineimap.__version__) +-self.bannerwin.addstr(0, 0, string, color) +-self.bannerwin.addstr(0, self.width -len(offlineimap.__copyright__) -1, +- offlineimap.__copyright__, color) ++string = "%s %s" % (offlineimap.__productname__, ++offlineimap.__version__) ++spaces = " " * max(1, (self.width - len(offlineimap.__copyright__) ++ - len(string) - 1)) ++string = "%s%s%s" % (string, spaces, offlineimap.__copyright__) ++self.bannerwin.addnstr(0, 0, string, self.width - 1, color) + self.bannerwin.noutrefresh() + + def draw_logwin(self): diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/series offlineimap-7.0.12+dfsg1/debian/patches/series --- offlineimap-7.0.12+dfsg1/debian/patches/series 2016-12-01 13:04:11.0 +0200 +++ offlineimap-7.0.12+dfsg1/debian/patches/series 2017-05-03
Bug#861636: FTBFS when sources imported into git
On 05/03/17 16:19, Dirk Eddelbuettel wrote: > But there isn't a lot I can do well, you could create the directory in the clean target.. and keep track of that by using find -type d -empty or so.. (yes, rather anyoing) > -- besides using my upstream bugzilla account > and filing this as https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17266 thanks ;) also there's another funny one: if you name the directory of the source tree something containing a tilde (in my case, 3.4.0-1~dschinn1 for my local stretch backport), then it FTBFS too. Regards, Daniel
Bug#859016: Processed: Re: Bug#859016: yadifa should drop ppc64el -O2 workaround
control: reopen 859016 thanks the patch has been upstreamed :( G. Il Mercoledì 3 Maggio 2017 18:45, Debian Bug Tracking Systemha scritto: Processing control commands: > fixed -1 2.2.3-1 Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround Marked as fixed in versions yadifa/2.2.3-1. > close -1 Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround Marked Bug as done -- 859016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859016 Debian Bug Tracking System Contact ow...@bugs.debian.org with problemsProcessing control commands: > fixed -1 2.2.3-1 Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround Marked as fixed in versions yadifa/2.2.3-1. > close -1 Bug #859016 [src:yadifa] yadifa should drop ppc64el -O2 workaround Marked Bug as done -- 859016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859016 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#861480: ImportError: No module named QtWebKit
On Sat, Apr 29, 2017 at 11:25:41PM +0200, Michal Čihař wrote: > Gammu/Wammu should work as well [1], though the GUI is probably not > that nice. > > [1]:https://wammu.eu/docs/manual/protocol/s60.html Unfortunately the gnapplet thing won't run on my S60 phone (Nokia C05 I think), so I cannot test wammu. Anyway, apparently the porting shouldn't be so difficult.
Bug#861575: tilix: Does not start on Stretch (symbol lookup error: undefined symbol)
Hey Jason, Thanks for looking it up! As a matter of fact, it looks like both libgtkd-3-0 and libvted-3-0 needs to be >= 3.5.1-1. Installing both libraries from unstable (both v.3.5.1-1) fixes the problem, and Tilix is able to run with it. Cheers, Mathieu. On 05/03/2017 01:42 AM, Jason Crain wrote: > On Sun, Apr 30, 2017 at 06:43:18PM -0400, Mathieu Basille wrote: >> Following the name change from terminix to tilix, I updated >> my Stretch system (which uses apt pining to install Sid >> packages whenever possible) to use the new developments of >> tilix. >> >> Install of v1.5.4-1 works without any problem, but I'm unable >> to run tilix: >> >> tilix: symbol lookup error: tilix: undefined symbol: >> >> _D7gobject7ObjectG7ObjectG11addOnNotifyMFDFC7gobject9ParamSpec9ParamSpecC7gobject7ObjectG7ObjectGZvAyaE4gtkc12gobjecttypes13GConnectFlagsZm > ... >> >> Versions of packages tilix depends on: >> ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 >> ii libc62.24-10 >> ii libgtkd-3-0 3.3.1-2 >> ii libphobos2-ldc71 1:1.1.1-1 >> ii libvted-3-0 3.3.1-2 >> ii libx11-6 2:1.6.4-3 >> ii tilix-common 1.5.4-1 > > tilix seems to require libgtkd-3-0 >= 3.5.1-1 and should have its > Depends increased. > -- Ce message est signé pour en assurer l'authenticité. Pour une correspondance avec moi réellement privée, utilisez ma clé publique pour chiffrer vos messages : http://mathieu.basille.net/pub.asc Plus d'infos : http://mzl.la/1BsOGiZ signature.asc Description: OpenPGP digital signature
Bug#778917: texlive-latex-extra: missing dependency - textgreek.sty requires lgrenc.def (texlive-lang-greek)
Package: texlive-latex-extra Version: 2016.20170123-5 Followup-For: Bug #778917 On 21 Feb 2015 21:01:04 +0100, Hilmar Preuße wrote: > On 21.02.2015 20:18, carandraug wrote: > > Hi, > >> The Tex textgreek package is part of the texlive-latex-extra debian package. >> This Tex package depends on lgrenc.def which in Debian, is part of the Debian >> texlive-lang-greek package. This package should then be listed as a >> dependency for texlive-latex-extra but it is not. > > Hmm. texlive-latex-extra has size of 33MB. texlive-lang-greek has a size > of 88MB. Forcing users to download and install 88MB just for a def file > having a size of 37KB won't make us friends. > Norbert, could you discuss this w/ upstream. Maybe moving the > "greek-fontenc" TeX package to an extra TeX Live package? > > Hilmar This issue is still present on Debian Stretch. It was not a problem on Wheezy because lgrenc.def was part of texlive-latex-base. I understand trying to avoid the 88MB dependency but at the moment that means that the textgreek package in texlive-latex-extra is broken which I would arguee is worse. Carnë -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-latex-extra depends on: ii preview-latex-style11.90-1 ii tex-common 6.06 ii texlive-base 2016.20170123-5 ii texlive-binaries 2016.20160513.41080.dfsg-2 ii texlive-latex-recommended 2016.20170123-5 ii texlive-pictures 2016.20170123-5 Versions of packages texlive-latex-extra recommends: ii texlive-fonts-recommended 2016.20170123-5 ii texlive-generic-extra 2016.20170123-5 ii texlive-latex-extra-doc2016.20170123-5 Versions of packages texlive-latex-extra suggests: ii libfile-which-perl 1.21-1 ii libspreadsheet-parseexcel-perl 0.6500-1 ii python-pygments 2.2.0+dfsg-1 Versions of packages tex-common depends on: ii dpkg 1.18.23 ii ucf 3.0036 Versions of packages tex-common suggests: ii debhelper 10.2.5 Versions of packages texlive-latex-extra is related to: ii tex-common6.06 ii texlive-binaries 2016.20160513.41080.dfsg-2 -- no debconf information
Bug#861759: libsane: Xsane fails to find Epson Perfection V600 Photo USB Scanner
Package: libsane Version: 1.0.24-8+deb8u1 Severity: important Dear Maintainer, Xsane fails to find the scanner. sane-find-scanner finds it at /dev/bus/usb/008/003 scanimage -l or scanimage -L fails to find it. I have installed the iscan package from Epson, as several reports indicates this includes a driver/wrapper that may help, but iscan is "unable to send comannd". /dev/bus/usb/008/003 is crw-rw-r--+ 1 root root - this could be a problem for regular users, but root is also unable to find the scanner with the same results as above. The scanner was working with current Jessie 32b upgraded through several versions of Debian, and I believe I may have solved a similar problem in the past, but I can not find my notes on that. (Sorry for the delay in re-reporting this, I had to re-install reportbug.) -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libsane depends on: ii acl2.2.52-2 ii adduser3.113+nmu3 ii libavahi-client3 0.6.31-5 ii libavahi-common3 0.6.31-5 ii libc6 2.19-18+deb8u7 ii libexif12 0.6.21-2 ii libgphoto2-6 2.5.4-1.1+b2 ii libgphoto2-port10 2.5.4-1.1+b2 ii libieee1284-3 0.2.11-12 ii libjpeg62-turbo1:1.3.1-12 ii libsane-common 1.0.24-8+deb8u1 ii libtiff5 4.0.3-12.3+deb8u2 ii libusb-1.0-0 2:1.0.19-1 ii libv4l-0 1.6.0-2 ii multiarch-support 2.19-18+deb8u7 ii udev 215-17+deb8u6 Versions of packages libsane recommends: ii libsane-extras 1.0.22.3 ii sane-utils 1.0.24-8+deb8u1 Versions of packages libsane suggests: ii avahi-daemon 0.6.31-5 ii hplip 3.14.6-1+deb8u1 pn hpoj -- no debconf information
Bug#861732: systemd: How to get suricata started at boot?
On 3 May 2017 at 18:33, Michael Bieblwrote: > [dropping debian-user from CC] > > Am 03.05.2017 um 17:39 schrieb Arturo Borrero Gonzalez: >> On 3 May 2017 at 12:36, Michael Biebl wrote: >>> Am 03.05.2017 um 11:11 schrieb Hans: Hello all, > >>> systemctl enable suricata.service >>> >>> will do the trick. That should be done by the package though. >> >> This conflicts with what was reported in #850889 [0]. >> >> I think both arguments are valid: >> >> 1) any suricata deployment is likely to require manual configuration >> before proper service. Auto-start makes no sense. >> 2) yes, we are debian, we like things running out of the box >> >> So, I'm unsure what path to follow. >> >> In any case, a fix is not landing in stretch at this point. We should >> wait for the stretch stable release. >> >> Comments/discussion welcome. >> >> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732 > > So, if I understand you correctly, suricata comes unconfigured > out-of-the-box? What does suricata do, it it is started anyway? > No, suricata comes pre-configured to run out of the box. You can run suricata with the basic configuration we ship in the package. The software is ready to run. But it requires rules (like a firewall) and the user setting some variables in order to let suricata know about the network environment, among other things. This is documented in our wiki [0]. Take into account that the user here is likely a system/network administrator. Someone who is supposed to know what is doing by installing suricata. [0] https://wiki.debian.org/suricata#Suricata_running_configuration
Bug#859016: yadifa should drop ppc64el -O2 workaround
control: fixed -1 2.2.3-1 control: close -1 On Wed, 29 Mar 2017 18:35:27 +0300 Adrian Bunkwrote: > On Wed, Mar 29, 2017 at 06:14:31PM +0300, Adrian Bunk wrote: > > Source: yadifa > > Version: 2.2.3-1 > > Severity: minor > > > > yadifa should drop fix-ppc64el_ftbfs.patch, > > the relevant gcc bugs are now fixed. > > > > There is no need to hurry and change this in stretch, > > but for stretch this workaround should be removed. > this is already fixed in Stretch, just it hasn't been mentioned in changelog. The patch has been commented in series file between 2.2.2-2 and 2.2.3-1 G. signature.asc Description: OpenPGP digital signature
Bug#861732: systemd: How to get suricata started at boot?
[dropping debian-user from CC] Am 03.05.2017 um 17:39 schrieb Arturo Borrero Gonzalez: > On 3 May 2017 at 12:36, Michael Bieblwrote: >> Am 03.05.2017 um 11:11 schrieb Hans: >>> Hello all, >> systemctl enable suricata.service >> >> will do the trick. That should be done by the package though. > > This conflicts with what was reported in #850889 [0]. > > I think both arguments are valid: > > 1) any suricata deployment is likely to require manual configuration > before proper service. Auto-start makes no sense. > 2) yes, we are debian, we like things running out of the box > > So, I'm unsure what path to follow. > > In any case, a fix is not landing in stretch at this point. We should > wait for the stretch stable release. > > Comments/discussion welcome. > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732 So, if I understand you correctly, suricata comes unconfigured out-of-the-box? What does suricata do, it it is started anyway? Is there a config file which needs to be created and you could test for in the systemd service file, with ConditionPathExists=/etc/my.config -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#798601: limereg: FTBFS on mips/mipsel
On Wed, May 03, 2017 at 05:19:37PM +0100, James Cowgill wrote: > It looks like this was just an uninitialized variable in > test_searchSubimage.c. Applying the attached patch fixes this issue for > me on mipsel. Thank you for the patch! Uploading :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#861169: Triaging and downgrading severity (includes rationale and suggestions)
severity 861169 important retitle 861169 systemd service overrides opendkim.conf socket at start thanks The previous report mentioned by the bug submitter is #853769. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769) >From that bug report, message #38 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769#38) says: Using the existing service file I confirmed that changes in /etc/opendkim.conf do affect the configuration of the running service after it is restarted. There's no change needed. Apparently, this not correct when the service is started, or at least in the specific way the submitter used to configure opendkim. Still, the behavior described in this new bug report is exactly how the sysvinit script behaves (according to #853769), which means the local admin is supposed to *override* this in the initscript. While this is NOT nearly as userfriendly as one might like, the *same* logic may be applied to systemd support if no better fix is possible at this time. IMHO, if a better choice is not available (e.g. due to security concerns or complexity of the required fix to avoid regressing any already-installed systems that depended on the initscript/systemd unit forced unix socket path), this could be properly documented in NEWS.debian/README.debian and also in the default /etc/ config file (and maybe as comments in the systemd unit and also the sysvinit initscript -- being through in these things pays off). I am downgrading this bug to important (which does *NOT* mean it should not be fixed, and if the fix is actually going to be just documentation, IMO that fix should be uploaded ASAP since it has zero regression risk and should be present in the next Debian stable if possible). Reasons for the severity downgrade: 1. It does *NOT* render the package unusable to the majority of its users, and it only affects more complex setups that would never work out-of-the-box without local configuration being done. 2. AFAIK, it matches previous behavior of Debian stable, and also when using initscripts instead of systemd. 3. It is not a regression in itself, and it doesn't cause regressions when the package is updated, as far as I can tell. 4. The issue it causes is going to be detected when the local admin is first configuring opendkim, and it is easy to work around (by editing the sysvinit script -- which is a conffile -- or by dropping an override for the systemd unit in the appropriate place under /etc). Bugs #853769 and #861169 are available as temporary documentation for the issue and provide hints to the required configuration change for the workaround. 5. The "grave" severity is very troublesome for every package depending on opendkim, and risks kicking all those packages out of the next Debian stable. -- Henrique Holschuh
Bug#861757: RFS: fonts-fandol/0.3-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "fonts-fandol" * Package name: fonts-fandol Version : 0.3-1 Upstream Author : Clerk Ma* URL : https://www.ctan.org/pkg/fandol * License : GPL-3 with fonts exception Section : fonts It builds those binary packages: fonts-fandol - Fandol fonts designed for Chinese typesetting To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fonts-fandol Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fonts-fandol/fonts-fandol_0.3-1.dsc Packaging Git repository: https://anonscm.debian.org/git/collab-maint/fonts-fandol.git Changes since the last upload: fonts-fandol (0.3-1) unstable; urgency=medium . * Initial release. (Closes: #861720) -- Sincerely, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#798601: limereg: FTBFS on mips/mipsel
Control: tags -1 patch Hi, I investigated this a bit by comparing in gdb a good version of limereg compiled without -Ofast and -fstack-protector and the original version. It looks like this was just an uninitialized variable in test_searchSubimage.c. Applying the attached patch fixes this issue for me on mipsel. Thanks, James --- a/tests/test_searchSubimage.c +++ b/tests/test_searchSubimage.c @@ -86,6 +86,7 @@ bool test_searchSubimage() const unsigned int skipLvl=2; struct Limereg_AdvancedRegControl advancedRegControl; advancedRegControl.maxIterations = 50; + advancedRegControl.stopSensitivity = 0; advancedRegControl.pyramidLevelCount = pyramidLvl; advancedRegControl.skipFineLevelCount = skipLvl; advancedRegControl.startParameters = signature.asc Description: OpenPGP digital signature
Bug#861497: gcc-6-cross: FTBFS in stretch
On Wed, May 03, 2017 at 01:40:12AM +0200, Matthias Klose wrote: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > > but it failed: > > fine, but you should make sure that this occurs in a distro environment as > well. I always do these test builds using sbuild in a chroot, as official autobuilders do. I also do "dpkg-buildpackage -A" or "dpkg-buildpackage -B" as official autobuilders do. So if by "distro environment" you meant I should use a chroot, I already do that. > > I've put the full build log here: > > > > https://people.debian.org/~sanvila/build-logs/gcc-6-cross/ > > for future reports, please could you keep a list of packages to check manually > for the errors? I tried to rebuild the package, and I couldn't even reproduce > this one. I already try to check before reporting. In this case, because the package takes a long time to build, I decided to do my "second" build not in my own autobuilders but in the reproducible builds autobuilders. So I tried twice in two different and unrelated autobuilders and I got two failures. Seemed good enough to me to report it as a bug. If the failures happened because of different reasons, as you say, then I'm very sorry for not having noticed, but in such case the problem is even worse, as it would mean that the package does not build reliably, or it fails to build randomly. When a the package fails to build randomly, you can't be sure that it does not fail randomly just by building it once, it could be just a matter of luck that it built ok that time. I have found more than 50 packages in stretch which FTBFS randomly so I can tell you for sure that such packages do exist. > PS: gcc-6-cross_22 was successfully built on the buildds. Glad to know, but such fact does not exclude that the package may fail randomly, so I would not consider this fixed just because of that. Thanks.
Bug#861364: dgit: empty directories are not representable
Nish Aravamudan writes ("Bug#861364: dgit: empty directories are not representable"): > On Wed, May 3, 2017 at 8:47 AM, Ian Jackson > > Call it a bug in git ? :-) I know that doesn't really help. > > Yeah -- Robie is working on fixing git. Coo! > > My initial plan was to simply ignore empty directories and hope that > > it didn't matter. If they do matter then we probably don't have a > > good answer. > > Agreed -- I think it is generically not possible to know if a given > empty directory matters or not. But it does mean if a goal is to > represent the exact contents of a given source package in the > corresponding git commit -- that's not achievable in the presence of > empty directories, at least by default. Yes. > I wanted to file this mostly so our importer and dgit did the same > thing for cases like this :) Stuff like this is one reason I haven't done a big historical import. After reifying such an import, it will be difficult to retrospectively fix this kind of problem. If you have an actual plan for fixing this then I would certainly like to hear it. If you have any non-awful workaround ideas, too. Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#861756: pd-pdstring: please make the build reproducible
Source: pd-pdstring Version: 0.10.2-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: environment X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that pd-pdstring could not be built reproducibly as it embeds the current username. Patch attached that modifies that patch I previously sent in #833445. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/common/m4/ax_pd_external.m4 2017-05-03 17:06:26.820444508 +0100 --- b/common/m4/ax_pd_external.m4 2017-05-03 17:10:13.613304235 +0100 @@ -244,10 +244,11 @@ ## compiled if test -n "$SOURCE_DATE_EPOCH"; then AC_DEFINE_UNQUOTED(PACKAGE_BUILD_DATE, "`LC_ALL=C date --utc --date="@$SOURCE_DATE_EPOCH"`", [Date this package was configured]) + AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER, "unknown",[User who configured this package]) else AC_DEFINE_UNQUOTED(PACKAGE_BUILD_DATE, "`date`", [Date this package was configured]) + AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER, "$USER",[User who configured this package]) fi - AC_DEFINE_UNQUOTED(PACKAGE_BUILD_USER, "$USER",[User who configured this package]) ## /compiled ##^^
Bug#861755: libpll: FTBFS on x86: AVX target specific option mismatch
Source: libpll Version: 0.0+20160909+ds1-1 Severity: serious Tags: upstream Justification: fails to build from source (but built successfully in the past) Builds of libpll on x86 architectures (even kfreebsd-amd64) fail too: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -msse3 -g -c core_partials_avx.c -fPIC -DPIC -o .libs/libpll_la-core_partials_avx.o core_partials_avx.c: In function 'pll_core_create_lookup_4x4_avx': core_partials_avx.c:155:11: warning: AVX vector return without AVX enabled changes the ABI [-Wpsabi] [...] /usr/lib/gcc/x86_64-kfreebsd-gnu/6/include/avxintrin.h:1270:1: error: inlining failed in call to always_inline '_mm256_set_epi64x': target specific option mismatch It appears to be performing CPU type detection at build time rather than runtime. As such, please specify --disable-avx everywhere and --disable-sse on i386 and ensure that the resulting configurations build. Thanks! FTR, I'm reporting this bug as a regression because I suspect it would affect binNMUs on amd64. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#861364: dgit: empty directories are not representable
On Wed, May 3, 2017 at 8:47 AM, Ian Jacksonwrote: > Nishanth Aravamudan writes ("Bug#861364: dgit: empty directories are not > representable"): >> At least src:software-properties has at one time had empty directories >> in the source package, e.g. in 0.96.20.5 in xenial on Ubuntu, and git >> (and thus dgit (via import-dsc) and the Ubuntu git importer) fail to >> properly represent the srcpkg's contents in the import. >> >> Specifically, tests/aptroot/etc/apt/apt.conf.d/ is missing from either >> import. > > Presumably the package breaks without this ? Yeah, in this case, a developer built a new srcpkg using our imported tree and it failed to pass the autopkgtests, which depended on this directory existing. >> Given that git does not represent empty directories, I'm not sure what >> we should do here? > > Call it a bug in git ? :-) I know that doesn't really help. Yeah -- Robie is working on fixing git. > My initial plan was to simply ignore empty directories and hope that > it didn't matter. If they do matter then we probably don't have a > good answer. Agreed -- I think it is generically not possible to know if a given empty directory matters or not. But it does mean if a goal is to represent the exact contents of a given source package in the corresponding git commit -- that's not achievable in the presence of empty directories, at least by default. I wanted to file this mostly so our importer and dgit did the same thing for cases like this :)
Bug#861754: libpll: FTBFS on non-x86: x86intrin.h: No such file or directory
Source: libpll Version: 0.0+20160909+ds1-1 Severity: important Tags: upstream Justification: fails to build from source Builds of libpll for non-x86 architectures have been failing: pll.h:28:23: fatal error: x86intrin.h: No such file or directory It looks like the build system already checks for this header, just doesn't (fully?) honor the check results; please conditionalize this #include directive on HAVE_X86INTRIN_H. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#861748: r-cran-rmpi: Loading library fails
On Wed, May 3, 2017 at 5:42 PM, Dirk Eddelbuettelwrote: > > I think I found it. Do an 'apt-get install libopenmpi-dev' and it will work. I was about to write that 'pkg-config --libs ompi' produces an error and that there is no libmpi.so on my system. After installing libopenmpi-dev, both symptoms go away and I am able to load the Rmpi library. thanks a lot! > Looks like we are missing an ldconfig run there. Is it really an ldconfig runthat is missing? To me it looks like the necessary link for libmpi.so is set-up by libopenmpi-dev and not libopenmpi2. So either r-cran-rmpi should (also) depend on libopenmpi-dev, or creating this link should be moved to libopenmpi2. Greetings Ralf
Bug#861364: dgit: empty directories are not representable
Nishanth Aravamudan writes ("Bug#861364: dgit: empty directories are not representable"): > At least src:software-properties has at one time had empty directories > in the source package, e.g. in 0.96.20.5 in xenial on Ubuntu, and git > (and thus dgit (via import-dsc) and the Ubuntu git importer) fail to > properly represent the srcpkg's contents in the import. > > Specifically, tests/aptroot/etc/apt/apt.conf.d/ is missing from either > import. Presumably the package breaks without this ? > Given that git does not represent empty directories, I'm not sure what > we should do here? Call it a bug in git ? :-) I know that doesn't really help. My initial plan was to simply ignore empty directories and hope that it didn't matter. If they do matter then we probably don't have a good answer. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#861474: slim: Session restarts in a loop renedering whole system useless.
Hi Mateusz, On 17:12 Tue 02 May , Apollon Oikonomopoulos wrote: > The attached debdiff resolves the restart loop, while ensuring that > slim plays nice with plymouth. If nobody responds, I intend to NMU the > package tomorrow. Would you like to update the package, or should I go ahead with the NMU as described above? Regards, Apollon
Bug#861748: r-cran-rmpi: Loading library fails
On 3 May 2017 at 09:36, Dirk Eddelbuettel wrote: | | This may have something to do with it: | | root@ef11adb9da1c:/# pkg-config --libs ompi | -L/usr/lib/x86_64-linux-gnu/openmpi/lib -L/usr//lib -lmpi | root@ef11adb9da1c:/# | | This is what we use at build-time. Yet: | | root@ef11adb9da1c:/# ls -l /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.* | lrwxrwxrwx 1 root root 16 Feb 10 05:43 /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so -> libmpi.so.20.0.2 | -rw-r--r-- 1 root root 919704 Feb 10 05:43 /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.20.0.2 | root@ef11adb9da1c:/# | root@ef11adb9da1c:/# ldconfig -p|grep libmpi.so | libmpi.so.20 (libc6,x86-64) => /lib/x86_64-linux-gnu/libmpi.so.20 | root@ef11adb9da1c:/# | | Looks like ldconfig is unaware of libmpi.so. But why? Maybe this? | | root@ef11adb9da1c:/# ls -l /etc/alternatives/libmpi* | lrwxrwxrwx 1 root root 47 May 3 14:26 /etc/alternatives/libmpi.so -> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so | lrwxrwxrwx 1 root root 51 May 3 14:26 /etc/alternatives/libmpi++.so -> /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so | root@ef11adb9da1c:/# | | Weirder still, now that I ran `ldconfig` a few times it loads (but dies over | an OpenMPI config wart in the Docker container I am in right now). I think I found it. Do an 'apt-get install libopenmpi-dev' and it will work. Looks like we are missing an ldconfig run there. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#861742: apt-cache showsrc reports errors for additional successful source package results
On 2017-05-03 15:08, schrieb David Kalnischkies wrote: I guess (= haven't looked too hard yet) that this is okay even through moving found_this should be enough already. I think so too. A patch should really come with a testcase through as this is just going to break one way or the other in the future otherwise. Especially as showsrc hasn't that many tests at all at the moment. Good point. Maybe it has broken because of this in the past. ;-) The README has some information on running and writing a test/integration script and looking at existing ones should be helpful, too, but feel free to ask here or on IRC (#debian-apt) if something isn't clear! I'm a little short of time atm, I don't know if I'm able to dig further into this. Nobody said that we like it, but reformatting means a lot of additional work nobody likes [...] agreed - delicate subject. I won't raise this topic again. Regards Michael
Bug#861732: systemd: How to get suricata started at boot?
On 3 May 2017 at 12:36, Michael Bieblwrote: > Am 03.05.2017 um 11:11 schrieb Hans: >> Hello all, >> >> I have installed suricata on my system, but it will not start at boot. >> >> When I manually start it, it is working well. >> >> As the document advises, I copied /lib/systemd/system/suricata.service to >> /etc/systemd/system/suricata.service and tested with > > You only need to copy suricata.service to /etc if you want to change its > contents. Even then, often drop-in snippets are preferrable, which only > override/extend the parts you need > >> systemctl start suricata.service >> >> "ps -aux | grep suricata" showed me the running process. But after reboot, >> the >> process is not started automatically. As init is no more supported by >> suricata, but systemd, > > The suricata package still ships a SysV init script, but if a systemd > service file exists, it takes precedence. > > how can I add this service into systemd, so that it is >> started automatically at boot? I am still not quite experienced with systemd. > > systemctl enable suricata.service > > will do the trick. That should be done by the package though. This conflicts with what was reported in #850889 [0]. I think both arguments are valid: 1) any suricata deployment is likely to require manual configuration before proper service. Auto-start makes no sense. 2) yes, we are debian, we like things running out of the box So, I'm unsure what path to follow. In any case, a fix is not landing in stretch at this point. We should wait for the stretch stable release. Comments/discussion welcome. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861732
Bug#861364: Acknowledgement (dgit: empty directories are not representable)
Note we are tracking the affected source packages which are hitting this at: https://bugs.launchpad.net/usd-importer/+bug/1687057.
Bug#858307: shotwell: https://picasaweb.google.com/data/feed/api/user/default returns HTTP 400
Hello Jérémy, google has shutdown picasa. So I close this bug. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser Threema: SYR8SJXB Wire: @joergfringsfuerst IRC: j_...@freenode.net j_...@oftc.net My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#819664: Suggestions to update the https://www.debian.org/CD/ page
> -- Original message -- > > To: debian-mirr...@lists.debian.org > Subject: Suggestions to update the https://www.debian.org/CD/ page > From: Matt Weeks> The https://www.debian.org/CD/ page seems a bit outdated. Is there someone > here who can update it? > > > I'd suggest changing > > "Due to space and bandwidth constraints, only very few mirrors are able to > supply direct HTTP/FTP download links. These sites may use bandwidth > throttling, downloads can be quite slow. Please use jigdo or bittorrent > instead. DVD images are only available for some architectures and not on all > mirrors." > > > To: > > "Many mirrors supply direct HTTP download links you can download with your > browser." Does someone disagrees about this change? If no one objects, I plan to commit the change this week-end. > > Broadband penetration has also dramatically increased, statistics in nearly > all the countries as I can find show that most users with internet access > (that can view this page) will also have broadband. E.g. Pew says 84% of U.S. > households own a computer, and 73% of households have broadband. China Daily > says Chinese speeds average 9.46 Mb/s. So I do not believe it is appropriate > any more to put the best option for dial-up at the top of the page. And while > there’s nothing wrong with jigdo or bittorrent, it will probably take the > average user more time to download, install, and open jigdo than to simply > download the iso from their closest mirror in their browser using the auto > mirror selector. > > > > Speaking of that, the automatic mirror selector has been working for over a > year now, so perhaps we should drop the “experimental” label and make it the > default as well. I do not think it is used for the iso links on > https://www.debian.org/distrib/ ? Do we plan to use it there? I have no idea about this point. signature.asc Description: OpenPGP digital signature
Bug#860747: dh_ruby: please inject versioned dependency on ruby metapackage
Control: severity 860747 serious Control: tag 860747 stretch-ignore jessie-ignore On 05/03/2017 04:27 PM, Antonio Terceiro wrote: > On Mon, May 01, 2017 at 01:12:19PM +0200, Julien Cristau wrote: >> On Wed, Apr 19, 2017 at 13:42:39 -0400, Aaron M. Ucko wrote: >> >>> Package: gem2deb >>> Version: 0.33.1 >>> Severity: normal >>> >>> Please have compiled Ruby extensions depend on compatible versions of >>> the ruby metapackage; for instance, an extension built only for 2.3 >>> would depend on ruby (>= 2.3), ruby (<< 2.4), and an extension built >>> for both 2.3 and 2.4 would depend on ruby (>= 2.3), ruby (<< 2.5). >>> (Python packaging settled on an analogous approach some time ago.) >>> Ideally, this dependency would go to a dedicated ${ruby:Depends} >>> substvar, but adding it to ${misc:Depends} would allow for much faster >>> adoption. >>> >>> As it stands, we can get situations like #860512, in which the m68k >>> build of telegram-desktop failed because ruby 2.3 wound up paired with >>> a ruby-fast-xs installation that only covered 2.2. (The 0.8.0-3+b2 >>> m68k binNMU was intended to add 2.3 support, but accidentally picked >>> up old metapackages.) With an explicit versioned dependency in place, >>> generic automated tools would have caught this problem. >>> >> As this allows broken package combinations, it seems to me the severity >> should be serious, not normal. > > fair enough. Can it algo be ignored for stretch? I reallt don't think we > should change that this late. > Sounds fair. Thanks, Julien