Bug#877054: #877054: hypre FTBFS with multiarch blas
Waiting for 2.11.2-1 to get through the NEW queue.
Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
Hello, I am also experiencing the same problem and can consistently reproduce it on both my laptop and desktop, which are both running Debian Stretch. I was able to reproduce a similar problem (x11 crashes instead of no input) in a qemu virtual machine, but for some reason it's not crashing anymore. How can I disable using libpam-systemd? I tried installing xserver-xorg-legacy, but it didn't change anything. Best regards, Matthew
Bug#877911: Please set CONFIG_BRCMFMAC_SDIO=y for WiFi on the Raspberry Pi 3
Source: linux Severity: wishlist Thanks for the linux/4.13.4-1 upload! On the Raspberry Pi 3, the Broadcom BRCM43430 chip is connected via SDIO. Hence, the brcmfmac driver’s config option CONFIG_BRCMFMAC_SDIO=y needs to be set, otherwise the driver won’t find the chip. I verified this works by recompiling the Debian kernel with CONFIG_BRCMFMAC_SDIO=y added to debian/config/arm64/config, and indeed the wlan0 interface newly shows up after rebooting into my kernel. Please include CONFIG_BRCMFMAC_SDIO=y in the next upload for arm64. Thank you! -- Best regards, Michael
Bug#873860: FTBFFS can't be in buster
control: tags -1 - buster thanks This FTBFS was caused by the upload of anthy to unstable/sid. Those broken versions are blocked by the RC bug to stay in unstable. The testing/buster has the same version of anthy as the one in stable/stretch. Thus tagging this as buster bug is wrong ;-) Also, my NMU'd version of anthy (once accepted to unstable) should fix issues in unstable and allow anthy package transition to buster without problem. So I am dropping the buster tag. Osamu
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
Control: reassign -1 locales On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote: > When Debian 9 is installed with the en-us locale selected, the clock defaults > to 24 hour time in the resulting install. This is odd because the normal means > of representing the time in the area covered by en-us is to separate the day > into two 12-hour segments. (localization issue) Actually, not two but four discontinuous segments: 12:00am..12:59am 01:00am..11:59am 12:00pm..12:59pm 01:00pm..11:59pm -- ie, even inside an am/pm value, the order is bizarre. Also, there's no way to unambigously refer to noon or midnight, or whether a midnight belongs to the previous or next day, as even the same users often keep shifting between two possible variants; you can read more about this horror at: https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight But, the above reasons apply mostly to humans. In a computing context, the main reasons are: * 12-hour times don't sort. Save for some GUIs where display is distinct from the internal format, most cases would do it wrong. And sorting by time is something with lots of use. * en_US (.UTF-8) is used as the default English locale for all places that don't have a specific variant (and often even then). Generally, technical users use English as a system locale as translations of computing terms tend to be a horror show: for example, in Polish even such a basic term as "file" has two versions ("zbiór" — correct, and "plik" — Microsoftese) that are not intelligible between some groups of people. Anything more complex gets bad enough that no one bothers translating advanced technical documentation or running servers (rather than user-facing systems) in pl_PL locale. And as far as I know, same applies to most languages. Obviously, this is an abuse, but that's the cost of being the default. If we had C.UTF-8 as a first-class locale, this wouldn't be that much an argument, but currently d-i falls back to en_US for English for most countries. The decision belongs to the maintainer (I'm reassigning), but per the above reasoning, I expect wontfix. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.
Bug#877910: irssi-plugin-xmpp: Fails to install due to conflict with irssi
Package: irssi-plugin-xmpp Version: 0.54-1 Severity: grave Justification: renders package unusable Trying to upgrade the package to 0.54-1 from 0.53-1+b1 fails with the following error: Preparing to unpack .../irssi-plugin-xmpp_0.54-1_amd64.deb ... Unpacking irssi-plugin-xmpp:amd64 (0.54-1) over (0.53-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/irssi-plugin-xmpp_0.54-1_amd64.deb (--unpack): trying to overwrite '/usr/share/irssi/help/ban', which is also in package irssi 1.0.4-1+b2 Errors were encountered while processing: /var/cache/apt/archives/irssi-plugin-xmpp_0.54-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) So it looks like some package needs a rebuild or a Breaks/Replaces config item needs to be added. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages irssi-plugin-xmpp depends on: ii irssi1.0.4-1+b2 ii libc62.24-17 ii libglib2.0-0 2.54.1-1 ii libloudmouth1-0 1.5.3-2 irssi-plugin-xmpp recommends no packages. irssi-plugin-xmpp suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#877909: NEW UPSTREAM 5 series VERSION !!!
Package: getmail4 Version: 4.53.0-1 Severity: important The watch file locks scanning of version to 4. So it loos only one version behind the upstream. But reality is different!!! | Version 5.4 | 6 October 2017 | -bugfix: fix another error in logging an error condition. Thanks: "ng0". | | Version 5.3 | 5 October 2017 | -bugfix: another case where an error condition resulted in getmail not | displaying the correct message. Thanks: "ng0". | | Version 5.2 | 4 October 2017 | -bugfix: disconnection during IMAP IDLE could result in an error message | rather than silently exiting. Thanks: David Gray. | | Version 5.1 | 15 July 2017 | -bugfix: if password_command parameter was used with a non-existent program, | getmail would error out during the handling of that condition and not report | the problem correctly. | | Version 5.0 | 15 July 2017 | -new release numbering scheme; previous version numbers were just getting | too high. | -catch and ignore/exit cleanly after reset connection in IMAP IDLE mode. | Thanks: Stephan Schulz. | -allow specifying an expected SSL certificate hostname, for when the | server's certificate does not match the domain name used to connect to | it. Thanks: "Andre". | -fix error message not actually giving the header field name incorrectly | specified as containing the envelope recipient address. Thanks: Hardy | Braunsdorf. | -add new password_command configuration parameter for retrievers, allowing | getmail to retrieve the account password from any arbitrary external | command. Suggestion: "ng0". | | Version 4.54.0 | 19 February 2017 | -fix error running getmail_fetch introduced in 4.53.0. Thanks: "fsckd" | of Arch Linux. (Actually, there are 5.0.0a1 and 5.0.0a2 from 2010 in the download directory. This was the reason why uscan was locked to version 4). So the game plan is to upload 4.54.0 to testing (maybe as 4.53.0-2), to pave the way to the stable-update upload. Then update the watch file and start uploading the 5 series! AS I see the daily updates for the last few days, waiting a bit may not be a bad idea. The question is do I upload as getmail, getmail4, or getmail5? Since there is no getmail in any active release, re-using "getmail" as the package name may be safe. This bug will be closed with the 5 series upload. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages getmail4 depends on: ii python 2.7.13-2 getmail4 recommends no packages. getmail4 suggests no packages. -- no debconf information
Bug#877838: clang-5.0: c++17 std::get(std::variant) fails to compile with libstdc++
It appears that clang is ignoring a friend declaration, while gcc is not. This simplified version of the program shows the problem: $ cat variant.cpp namespace __detail { namespace __variant { template decltype(auto) __get(const T &t) { return t.i_; } } } template class variant { public: variant(const T &t) : i_(t) {} template friend decltype(auto) __detail::__variant::__get(const Type &); private: T i_; }; int main() { variant v{2}; return __detail::__variant::__get(v); } $ g++-7 variant.cpp -std=c++1z $ clang++-5.0 variant.cpp -std=c++1z variant.cpp:6:12: error: 'i_' is a private member of 'variant' return t.i_; ^ variant.cpp:24:31: note: in instantiation of function template specialization '__detail::__variant::__get >' requested here return __detail::__variant::__get(v); ^ variant.cpp:18:5: note: declared private here T i_; ^ 1 error generated. I suspect this might be related to the use of decltype(auto), but I don't know anything about clang internals to investigate more. I've also tried clang-6.0 from unstable and the output is similar. I'd appreciate any help. Thanks! Daniele
Bug#497859: Gruß
In kurzen Einleitung Ich bin ein Anwalt Meinze Klaus Peter, aus Deutschland, ich lebe jetzt in London jetzt, ich habe dir eine E-Mail über dein verstorbenes Familienmitglied verspätete Familie geschickt, ich habe keine Antwort von dir erhalten. Der Verstorbene ist ein Bürger in deinem Land mit demselben Nachname mit dir Er ist ein Gold-Exporteur hier in London, mein Klient starb vor ein paar Jahren mit seiner Familie, die sein Geschäft verlassen und riesige Geldbeträge £ 5,7 Millionen bei GBP Investment Bank hier in London, ich bin der persönliche Anwalt des verspäteten Klienten, und ich brauche Ihre volle Zusammenarbeit, soweit wir das Geld von der Bank nehmen können, bevor die Regierung es endlich nimmt. Der Gesamtbetrag in der Die Bank ist £ 5,7 Millionen, GBP aber wird erklären, mehr Details, wenn ich von Ihnen zu hören Ich brauche jetzt deine Antwort?
Bug#877908: ITP: libweasel-widgets-dojo-perl - Dojo Widgits for Weasel
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libweasel-widgets-dojo-perl Version : 0.02 Upstream Author : Erik Huelsmann * URL or Web page : https://metacpan.org/pod/Weasel::Widgets::Dojo * License : perl Description : Weasel::Widgets::Dojo - Dojo Widgits for Weasel The Weasel::Widgets::Dojo module is a Weasel extension set for testing Dojo-based web apps (tag matchers and widgets). -- Robert J. Clay rjc...@gmail.com
Bug#877907: music ftbfs on all archs except for amd64
Package: src:music Version: 1.0.7-1.3 Severity: serious Tags: sid buster see https://buildd.debian.org/status/package.php?p=music make[2]: Leaving directory '/<>' ( cd /<>/debian/tmp/usr/lib/x86_64-linux-gnu; chrpath -d libmusic.so libmusic-c.so ) /bin/sh: 1: cd: can't cd to /<>/debian/tmp/usr/lib/x86_64-linux-gnu open: No such file or directory elf_open: Invalid argument debian/rules:10: recipe for target 'override_dh_auto_install' failed make[1]: *** [override_dh_auto_install] Error 1 make[1]: Leaving directory '/<>' debian/rules:7: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2
Bug#877895: intersphinx plugin makes packages unreproducible
[taking the liberty to add back the BTS in CC, I hope that's okay] On 2017-10-06 22:20:11, Daniel Shahaf wrote: > Antoine Beaupre wrote on Fri, Oct 06, 2017 at 15:51:46 -0400: >> -to_addr (> href="https://docs.python.org/3/library/stdtypes.html#str"; title="(in Python >> v3.6)">str) – the email to use as “to” (defaults to >> +to_addr (str) – the email to use as “to” >> (defaults to > > problem is the interlinks mapping is sometimes more than stdlib > (like in my case) > gtg > > In this case, the solution I described on IRC works more generally... > > If python3-foo's docs link to python3-bar's, then have python3-foo > build-depend on python3-bar, have python3-bar provide a parseable > documentation index, and have python3-foo's build use that index. I believe that those docs package already do provide docs index, e.g.: /usr/share/doc/python-configparser/html/objects.inv it's just a matter of fixing sphinx to make that work then... i wonder if interlinks supports file:// paths? a. -- I believe that if someone choose arts as their subject but do not criticize the issues of their society, they have have betrayed themselves, their conscience, and their society. - Atena Farghadani
Bug#877679: [Openjdk] Bug#877679: java-8-openjdk (version 8u141-b15-1~deb9u1) fails to install if /usr/share/man is not available
Control: severity -1 wishlist On 04.10.2017 11:52, Mattia Rizzolo wrote: > Control: reassign -1 openjdk-8-jre-headless 8u141-b15-1~deb9u1 > Control: severity -1 serious no. why? Please don't exaggerate bug severities without looking at them. > On Tue, Oct 03, 2017 at 09:47:12PM +0200, Olliver Schinagl wrote: >> Package: java-8-openjdk >> >> Version 8u141-b15-1~deb9u1 > > Please use reportbug to report your bugs if you are unsure about the the > proper syntax: the package you mentioned doesn't exist, and the version > line lacks a column. > >> Severity: normal > > failures to install are serious bugs. no, not if the user choose to drop installation of manual pages, and the infrastructure is broken not to handle creating symlinks for these cases. If you want to help, please find an appropriate package and reassign. We had these bug reports before. > Reassigning and leaving the rest of the message as a context for the > maintainer. > >> When setting up java-8-openjdk on a minimal debian (where I would have rm >> -rf-ed /usr/share/man) the following snipped shows the failure error. >> >> I have had a similar error with postgres which was fixed in Bug#866729 >> >> update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/rmid to >> provide /usr/bin/rmid (rmid) in auto mode >> update-alternatives: error: error creating symbolic link >> '/usr/share/man/man1/rmid.1.gz.dpkg-tmp': No such file or directory >> dpkg: error processing package openjdk-8-jre-headless:amd64 (--configure): >> subprocess installed post-installation script returned error exit status 2 >> dpkg: dependency problems prevent configuration of >> openjdk-8-jdk-headless:amd64: >> openjdk-8-jdk-headless:amd64 depends on openjdk-8-jre-headless (= >> 8u141-b15-1~deb9u1); however: >> Package openjdk-8-jre-headless:amd64 is not configured yet. >> >> Thank you, >> >> Olliver > > > > ___ > Mailing list: https://launchpad.net/~openjdk > Post to : open...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openjdk > More help : https://help.launchpad.net/ListHelp >
Bug#877418: dh-strip-nondeterminism: kills clojure performance
On Fri 2017-10-06 10:00:27 +0100, Chris Lamb wrote: > If it were hardcoded into the filenames, one wouldn't need to do > anything onerous, eg. > > -rw-r--r-- 1 0 Oct 6 09:56 > helloworld.adc83b19e793491b1c6ea0fd8b46cd9f32e592fc.class > -rw-r--r-- 1 0 Oct 6 09:56 > helloworld.adc83b19e793491b1c6ea0fd8b46cd9f32e592fc.clj > > (Not entirely serious) ah! i hadn't even thought of that :) I wonder whether any language would consider such a construct. > Just to underline, Python in Debian would not be a problem even with < > unless you consider building a .deb with SOURCE_DATE_EPOCH="$(date +%s)" > and installing that very same .deb within same second... > > … but I understand you were being more general about this topic! yep, exactly -- i'm not saying that python is broken in debian, just citing it as an example of another language that does the same kind of thing, similarly to elisp, etc. --dkg
Bug#877906: hwinfo: hangs forever at > bios.2: ram
Package: hwinfo Version: 21.49-1 Severity: normal Dear Maintainer, Running "hwinfo --bios" displays things overtyping itself then hangs forever with "> bios.2: ram" displayed. Running it in strace shows that this is just after it opens /dev/mem Thanks for any assistance or advice you can offer. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hwinfo depends on: ii libc62.24-11+deb9u1 ii libhd21 21.49-1 hwinfo recommends no packages. hwinfo suggests no packages. -- debconf-show failed
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
a bit late but great work! please upload to debian.. Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-10-06 17:46 GMT-04:00 Michael Stapelberg : > Indeed, I can confirm that compilation works now. Can you upload the > package to Debian please? :) > > On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS) > wrote: > > On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg > > wrote: > >> Thanks for sharing! The Debian package builds fine. However, when > >> trying to use cc65 to compile a project of mine, compilation fails > >> with “include/general.h(4): Error: Include file `peekpoke.h' not > >> found”. > > Please fetch and build again. Should be fixed. > > > > Laszlo/GCS > > > > -- > Best regards, > Michael >
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1
This is affecting EAP with wpa_supplicant. See https://bugs.debian.org/877904
Bug#877905: lintian: False positive for dh-exec-script-without-dh-exec-features
Package: lintian Version: 2.5.54 The following working dh-exec file (from gpm 1.20.7-3, currently in Experimental) triggers the lintian warning dh-exec-script-without-dh-exec-features despite it clearly uses dh-exec features: ---8<--- #!/usr/bin/dh-exec contrib/control/gpm_has_mouse_control usr/lib/gpm/ contrib/scripts/microtouch-setup=> usr/sbin/gpm-microtouch-setup debian/gpm.apm => etc/apm/event.d/gpm src/prog/mouse-test => usr/sbin/gpm-mouse-test src/gpmusr/sbin/ src/prog/mev usr/bin/ --->8--- Reason seems to be that the file uses tabs instead of simple blanks in front of the "=>" arrow. I think, I'll already found the code which causes this, so I'll very likely add a commit to fix this soon. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-rc7-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils 2.29.1-4 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.18.24 ii file 1:5.32-1 ii gettext 0.19.8.1-4 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b2 ii libdigest-sha-perl5.98-1 ii libdpkg-perl 1.18.24 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.0-8 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.72-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.63-2+b2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.26.0-8 ii t1utils 1.40-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: ii binutils-multiarch 2.29.1-4 ii dpkg-dev 1.18.24 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.47-1 -- no debconf information
Bug#877687: pidgin: (xmpp) checks wrong certificate when connecting to explicit server
Are you sure this isn't intended behavior? Why should pidgin trust the hostname on a certificate just because it matches the ID? If anything, it seems like having that behavior for a SRV record would be a bug.
Bug#877904: EAP: TLS version too low
Package: wpa Version: 2:2.6-4 OpenSSL 1.1.0f-5 will not by default negotiate a version of TLS lower than 1.2. I'm having an issue with EAP authentication that seems related to this. With openssl 1.1.0f-3 installed: wpa_supplicant[30538]: wlp3s0: SME: Trying to authenticate with xx:xx:.. (SSID='UPC Wi-Free' freq=2437 MHz) wpa_supplicant[30538]: wlp3s0: Trying to associate with xx:xx:.. (SSID='UPC Wi-Free' freq=2437 MHz) wpa_supplicant[30538]: wlp3s0: Associated with xx:xx:.. wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication started wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=NL/O=Liberty Global Operations B.V./OU=Root CA0001/CN=Liberty Global Root Certification Authority' hash=... wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=NL/O=Liberty Global Operations B.V./OU=Root CA0001/CN=Liberty Global Root Certification Authority' hash=... wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=NL/O=Liberty Global Operations B.V./OU=HORIZON Service Operator CA0001/CN=Liberty Global HORIZON Service Operator Certification Authority' hash=... wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=NL/O=LGI/OU=HORIZON/CN=Liberty Global WiFi 0001' hash=... wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:wifi-auth.upc.biz wpa_supplicant[30538]: EAP-MSCHAPV2: Authentication succeeded wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully wpa_supplicant[30538]: EAPOL: Received IEEE 802.1X EAPOL-Key even though this was not accepted - ignoring this packet wpa_supplicant[30538]: wlp3s0: WPA: Key negotiation completed with xx:xx:.. [PTK=CCMP GTK=TKIP] wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-CONNECTED - Connection to xx:xx:.. completed [id=0 id_str=] wpa_supplicant[30538]: EAPOL: Received IEEE 802.1X EAPOL-Key even though this was not accepted - ignoring this packet wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-49 noise= txrate=144400 With 1.1.0f-5 installed: wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SSID-REENABLED id=0 ssid="UPC Wi-Free" wpa_supplicant[32704]: wlp3s0: SME: Trying to authenticate with xx:xx:.. (SSID='UPC Wi-Free' freq=2412 MHz) wpa_supplicant[32704]: wlp3s0: Trying to associate with xx:xx:.. (SSID='UPC Wi-Free' freq=2412 MHz) wpa_supplicant[32704]: wlp3s0: Associated with xx:xx:.. wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication started wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected wpa_supplicant[32704]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version wpa_supplicant[32704]: OpenSSL: openssl_handshake - SSL_connect error:1417118C:SSL routines:tls_process_server_hello:version too low wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed wpa_supplicant[32704]: wlp3s0: Authentication with xx:xx:.. timed out. wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:.. reason=3 locally_generated=1 wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="UPC Wi-Free" auth_failures=2 duration=37 reason=AUTH_FAILED Related bug reports: https://bugs.debian.org/875423 https://bugs.debian.org/871987 https://bugs.debian.org/873302 Regards, Gedalya
Bug#866118: unattended-upgrades: test suite reads files from /etc/apt
Control: fixed -1 0.96 Hi Raphael, On Tue, 27 Jun 2017 15:36:36 +0200 Raphael Geissert wrote: > Package: unattended-upgrades > Version: 0.93.1+nmu1 > > Hi, > > As discussed via IRC, unattended-upgrades' test suite appears to read > files from the host's /etc/apt/, which may at least make it fail. > > For instance, test_minimal_partitions uses apt.Cache which ends up > reading the preferences files. > Given an environment where those files are not world-readable the test > suite fails. This made builds on buildds fail, too, but it is fixed now. Cheers, Balint
Bug#643680: Could I ask for a reproducer?
Hi, this is your happy upstream maintainer of M2Crypto. I tried to reproduce this bug here, but I have failed so far. Could you be so kind and and provide some complete standalone testing script together with all data files (certificates, etc.) needed for the reproduction, please? If I can reproduce the problem, I will gladly try to fix it. Thank you for reporting this, Matěj Cepl signature.asc Description: OpenPGP digital signature
Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?
On 10/06/2017 02:28 PM, Salvatore Bonaccorso wrote: Control: notfixed -1 1.2.8p26-1 Hi! On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:check-mk package: #865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py I looked up the source for 1.2.8p26-1. The fix for CVE-2017-9781 is http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1 which does not yet seem to be applied to 1.2.8p26-1? Can you please double-check? Note, there is a second CVE now for check-mk, that one got addressed in 1.2.8p26, but it's not clear yet in which version in was introduced. Hi, You are right, the fix for CVE-2017-9781, which upstream calls "werk #4757" is _not_ in 1.2.8p26. I was confused with upstream #5208 when I wrote the changelog that closed the bug. Upstream lists the following security related fixes for 1.2.8 == #5208 http://mathias-kettner.com/check_mk_werks.php?werk_id=5208&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=673360408b90f99bd54cf936091cff08d979a057 #4902 http://mathias-kettner.com/check_mk_werks.php?werk_id=4902&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=96e39a0f024d9b2b521576c1eb71aca7fb3e818d #7661 (fixed in 1.4.0p8, supposedly fixed in 1.2.8p25?) http://mathias-kettner.com/check_mk_werks.php?werk_id=7661&HTML=yes #7631 http://mathias-kettner.com/check_mk_werks.php?werk_id=7631&HTML=yes #3970 (fixed in 1.2.8p14) http://mathias-kettner.com/check_mk_werks.php?werk_id=3970&HTML=yes #3855 (fixed in 1.2.8p11) http://mathias-kettner.com/check_mk_werks.php?werk_id=3855&HTML=yes #3743 (fixed in 1.2.8p10) http://mathias-kettner.com/check_mk_werks.php?werk_id=3743&HTML=yes Full list of changes for 1.2.8p26 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw&branch=1.2.8&version=1.2.8p26&HTML=yes Full list of changes for 1.4.0p14 = http://mathias-kettner.com/check_mk_werks.php?edition_id=raw&branch=1.4.0&version=1.4.0p14&HTML=yes which additionally lists #4757 (as you mentioned above, fixed in 1.4.0p6) http://mathias-kettner.com/check_mk_werks.php?werk_id=4757&HTML=yes http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=14a5b79c6f549502244a60146ed6831dc3473f2a #7643 (only in 1.4 and newer) http://mathias-kettner.com/check_mk_werks.php?werk_id=7643&HTML=yes So I think the Debian 1.2.8p16 package is only missing #4757. I will ask upstream if they intend to fix #4757 in the 1.2.8 series. Unfortunately due to how the upstream tarball/build works, it is tricky to patch upstream files. If upstream doesn't intend to include this fix I can generate a patch to make it work. I had started working on packaging 1.4.0 as a way to fix these security bugs (and even did an upload to experimental) but I recently learned from upstream that: "The use of Check_MK without OMD environment and customization of paths is explicitly not supported anymore." ie you can't use check-mk stand-alone, you have to use OMD (and livestatus/WATO/multisite, the whole stack) and you have to use upstream's installer to upstream's paths. It's very much the "network appliance" model (or flatpak, docker image, etc) I don't know if we'll be able to make this work in Debian. (not to mention that nagios is gone and icinga1 will go away at some point) That prompted me to go back to 1.2.8 and package the latest release there in order to at least have something working without the security bugs. -- Matt Taggart tagg...@debian.org
Bug#877903: CVE-2017-15037
Source: kfreebsd-10 Severity: important Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15037 Cheers, Moritz
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
Indeed, I can confirm that compilation works now. Can you upload the package to Debian please? :) On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS) wrote: > On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg > wrote: >> Thanks for sharing! The Debian package builds fine. However, when >> trying to use cc65 to compile a project of mine, compilation fails >> with “include/general.h(4): Error: Include file `peekpoke.h' not >> found”. > Please fetch and build again. Should be fixed. > > Laszlo/GCS -- Best regards, Michael
Bug#877902: ftp.debian.org: removals.822 contains invalid stanzas
Package: ftp.debian.org Severity: normal I've written a local script (to be submitted to devscripts) that parses the removals.822, but it seems the generated one(s) is bogus. We have for example joined stanzas, which make the parser trip over the duplicate field: [ error: syntax error in Debian package removals at line 11506: duplicate field Date found ] ,--- Date: Sat, 01 Apr 2017 00:00:14 + Ftpmaster: Scott Kitterman Suite: unstable Sources: libdc0_0.3.24~svn3121-4 Binaries: libdc-dev_0.3.24~svn3121-4 [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] libdc5v5_0.3.24~svn3121-4 [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] Reason: RoQA; unmaintained, dead upstream, low popcon, library with no rdeps Bug: 761989 Date: Sat, 01 Apr 2017 14:22:46 + Ftpmaster: DAK's auto-decrufter Suite: experimental Sources: wine_1.8.7-1 Binaries: fonts-wine_1.8.7-1 [all] libwine_1.8.7-1 [amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc] libwine-dev_1.8.7-1 [amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc] wine_1.8.7-1 [all] wine-binfmt_1.8.7-1 [all] wine32_1.8.7-1 [armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc] wine32-preloader_1.8.7-1 [armel, armhf, i386, powerpc] wine32-tools_1.8.7-1 [armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc] wine64_1.8.7-1 [amd64, arm64] wine64-preloader_1.8.7-1 [amd64] wine64-tools_1.8.7-1 [amd64, arm64] Reason: [auto-cruft] NVIU `--- [ error: syntax error in Debian package removals at line 13372: line with unknown format (not field-colon-value) ] ,--- Date: sh: 0: getcwd() failed: No such file or directory Sat, 06 May 2017 08:45:30 + Ftpmaster: Chris Lamb Suite: unstable Binaries: rnahybrid_2.1.2-1 [armel] Reason: ROM; Does not build on armel Bug: 861794 Date: Sat, 06 May 2017 08:45:49 + Ftpmaster: Chris Lamb Suite: unstable Sources: cpp-netlib_0.11.2+dfsg1-2 Binaries: libcppnetlib-dev_0.11.2+dfsg1-2+b1 [arm64, hurd-i386, kfreebsd-amd64, kfreebsd-i386] libcppnetlib-dev_0.11.2+dfsg1-2+b3 [amd64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] libcppnetlib-doc_0.11.2+dfsg1-2 [all] libcppnetlib0_0.11.2+dfsg1-2+b1 [arm64, hurd-i386, kfreebsd-amd64, kfreebsd-i386] libcppnetlib0_0.11.2+dfsg1-2+b3 [amd64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x] Reason: ROM; Doesn't work against current libboost, no time to maintain it Bug: 861888 Also-Bugs: 834186 Also-WNPP: 857461 `--- Thanks, Guillem
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
Package: general Severity: minor Dear Maintainer, When Debian 9 is installed with the en-us locale selected, the clock defaults to 24 hour time in the resulting install. This is odd because the normal means of representing the time in the area covered by en-us is to separate the day into two 12-hour segments. (localization issue) -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#877901: libseccomp: Test failures should cause the build to fail
Package: libseccomp Version: 2.3.1-2.1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu artful ubuntu-patch Dear Maintainer, While doing some work on libseccomp in Ubuntu, I noticed that the exit code of the `make check` target was being ignored despite the tests passing on all architectures we build on. I think we should make test failures be fatal for the build as the old issues that caused Debian bug 721292 seem to have been fixed. In Ubuntu, the attached patch was applied to achieve the following: * debian/rules: Make test failures cause the build to fail (LP: #1657425) To test the attached patch, I injected a fake test failure into tests/13-basic-attrs.py and verified that the subsequent build failed. Thanks for considering the patch. Tyler -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (400, 'xenial-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-96-generic (SMP w/12 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) diff -Nru libseccomp-2.3.1/debian/rules libseccomp-2.3.1/debian/rules --- libseccomp-2.3.1/debian/rules 2016-11-17 17:23:10.0 + +++ libseccomp-2.3.1/debian/rules 2017-10-06 18:08:35.0 + @@ -29,9 +29,3 @@ "usr/lib/$(DEB_HOST_MULTIARCH)/libseccomp.so.*" \ lib/$(DEB_HOST_MULTIARCH) dh_install --remaining-packages --list-missing - -override_dh_auto_test: -ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) - make check 2>&1 | tee regression.out && \ - grep -q "^ tests failed: 0" regression.out || true -endif
Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?
Control: notfixed -1 1.2.8p26-1 Hi! On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:check-mk package: > > #865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py I looked up the source for 1.2.8p26-1. The fix for CVE-2017-9781 is http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1 which does not yet seem to be applied to 1.2.8p26-1? Can you please double-check? Note, there is a second CVE now for check-mk, that one got addressed in 1.2.8p26, but it's not clear yet in which version in was introduced. Regards, Salvatore
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg wrote: > Thanks for sharing! The Debian package builds fine. However, when > trying to use cc65 to compile a project of mine, compilation fails > with “include/general.h(4): Error: Include file `peekpoke.h' not > found”. Please fetch and build again. Should be fixed. Laszlo/GCS
Bug#862657: Weird setup
Hi! I'm revisiting this bug and I still don't get the setup, it looks quite weird to me. br0 connected to eth0.6 (vlan 6) br1 connected to eth0.7 (vlan 7) br2 connected to eth0 It seems logic to me that putting br2 down also takes down eth0, the problem here is that eth0 is also part of the other bridges. What is the reason of using several bridges bound to the same physical interfaces? I believe this isn't even a supported setup, in fact if one tries to bridge the same interface to a couple of bridges this won't be allowed: device eth0 is already a member of a bridge; can't enslave it to bridge br0. So, I believe this bug should be closed unless ther is something useful to do with the weird setup. There is an easy way to fix this bug, it would be to not put down the interfaces when putting down the bridge, but I don't really like this. What do you think? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#877899: RM: gtable -- RoQA; binary package taken over by src:r-cran-gtable
Package: ftp.debian.org Severity: normal Dear ftpmasters, Please remove src:gtable from the archive. The binary package that it built (r-cran-gtable) has been taken over by src:r-cran-gtable. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#877898: RM: zelig -- RoQA; binary package taken over by src:r-cran-zelig
Package: ftp.debian.org Severity: normal Dear ftpmasters, Please remove src:zelig from the archive. The binary package that it built (r-cran-zelig) has been taken over by src:r-cran-zelig. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#744112: Release is being prepared
Hi, the Debian 3dprinter team is preparing a release of the new CuraEngine and the rest of the Cura packages: https://anonscm.debian.org/cgit/3dprinter/packages/cura-engine.git/ https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/ We're still working on 2.5, but 2.7 or 3.0 will be released shortly after the packages are in Debian.
Bug#877897: RFS: wxmaxima/17.10.0-3
On Fri, 2017-10-06 at 22:25 +0200, Gunter Königsmann wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am afraid this time I have made another bug in my package "wxmaxima" > and therefore kindly ask you to sponsor another upload. > > * Package name: wxmaxima > Version : 17.10.0-3 > Upstream Author : Andrej Vopodivec > * URL : http://andrejv.github.io/wxmaxima/ > * License : GPL-2 > Section : math > > It builds those binary packages: > > wxmaxima - GUI for the computer algebra system Maxima > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/wxmaxima > > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_17.10.0-2.dsc > > wxMaxima is a powerful graphical front-end for maxima, a program that > does symbolic algebra. An example: > > (%i1) val:[ > a=10, > b=sqrt(2), > c=5 > ]; > (val) [a=10,b=sqrt(2),c=5] > > (%i2) poly:y=a*x^2+b*x+c$ > > (%i3) solve(poly,x); > (%o3) [x=-(sqrt(4*a*y-4*a*c+b^2)+b)/(2*a),x=(sqrt(4*a*y-4*a*c+b^2)- > b)/(2*a)] > > (%i4) subst(y=0,%); > (%o4) [x=-(sqrt(b^2-4*a*c)+b)/(2*a),x=(sqrt(b^2-4*a*c)-b)/(2*a)] > > (%i5) subst(val,%); > (%o5) [x=-(3*sqrt(22)*%i+sqrt(2))/20,x=(3*sqrt(22)*%i-sqrt(2))/20] > > (%i6) rectform(float(%)); > (%o6) > [x=-0.7035623639735145*%i-0.07071067811865477,x=0.7035623639735145*%i- > 0.07071067811865477] > > > Don't know why mentors.debian.net doesn't like my watchfile: uscan does. > If anybody has an idea how to make it work for mentors, too, I will > prepare a new wxMaxima package that fixes this. > > > Changes since the last upload: > > Re-Added an accidentally-dropped dependency. > > Regards, > Gunter Königsmann > Hi, Regards For watch file query. See: https://wiki.debian.org/debian/watch#GitHub Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org GitLab: https://gitlab.com/kathenas Twitter: kathenasorg Instagram: kathenasorg GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A signature.asc Description: This is a digitally signed message part
Bug#876654: prosody: incompatible lua-sec version as dependency of prosody in stable
Hi, On Sun, 24 Sep 2017 16:16:59 +0200 Leah Oswald wrote: > It seems that this bug occures becaus the package lua5.1-sec that is a > dependency of prosody resolves to the lua-sec package with version 0.6-3 > in debian stretch. But lua-sec with version 0.6 isn't supported by > prosody 0.9.x. See: https://prosody.im/doc/depends > > It seems this issue makes prosody mostly unusable for encrypted > connections. I don't think this analysis is correct. I've tested connecting prosody with jabber.ccc-mannheim.de on stretch and captured the packets. The two sides just can't agree on a TLS cipher/curve. jabber.ccc-mannheim.de supports only ECDHE ciphers and the secp256r1 (aka prime256v1) curve. Prosody by default allows only the secp384r1 curve. You can verify this with: openssl s_client -cipher ECDHE-RSA-AES128-GCM-SHA256 -curves prime256v1 -starttls xmpp-server -connect falster.c3ma.de:xmpp-server works openssl s_client -cipher ECDHE-RSA-AES128-GCM-SHA256 -curves secp384r1 -starttls xmpp-server -connect falster.c3ma.de:xmpp-server fails You can of course argue whether allowing only secp384r1 is a good default. Felix
Bug#877629: wordpress: CVE-2017-14990
Hi Yves-Alexis, I have now applied that patch to the stretch version of wordpress. Other than some minor problems (some comments had changed) the patch applied cleanly. You'll find the update at https://anonscm.debian.org/git/collab-maint/wordpress.git/commit/?h=stretch&id=5c88ea7390caed18e9c986294d45f6c7f718740b Hopefully we can get the security release out before the next set of WordPress security issues! - Craig -- Craig Small https://dropbear.xyz/ csmall at : enc.com.au Debian GNU/Linuxhttps://www.debian.org/ csmall at : debian.org Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Bug#865986: stretch-pu: package openssh/1:7.4p1-10+deb9u2
Control: tag -1 - moreinfo On Mon, Jun 26, 2017 at 01:57:25PM +0200, Cyril Brulebois wrote: > Colin Watson (2017-06-26): > > I've committed this patch to master, but it isn't in unstable yet > > because I'm waiting for openssh-ssh1 to clear NEW before I upload > > openssh to unstable again, in order to avoid confusion with versions. > > However, point release dates are close enough that I wanted to seek > > approval for this sooner rather than later. > > I was surprised by the double ExecReload entry at first, but that seems > to be allowed. Moreover, that keeps sshd alive when a typo is willingly > introduced in sshd_config. > > (Granted: Tested on a jessie system only.) > > This looks good to me. I'll wait until the bug fix clears NEW, and until > you post a final debdiff, targetting stretch, to tag this request with > the "confirmed" tag. I got kind of distracted and forgot about this, and in the meantime a few more bugs have become evident that ought to be fixed in stable, so here's an extended debdiff for approval. * #877800 causes current versions of WinSCP to be unable to connect due to overly-general version patterns in sshd's bug-compatibility code. * #873201 was implicated in a few CVEs a while back in packages using ssh; I'm not sure whether it *quite* counts as a security vulnerability in and of itself, but we should fix it anyway. (And yes, I'll deal with these in jessie too as necessary as soon as I summon the energy for oldstable updates.) A current version of git introduced a small amount of noise into the diff, but it's small enough that I don't think it's worth brutalising the tools to avoid it. diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm --- openssh-7.4p1/debian/.git-dpm 2017-06-18 01:08:18.0 +0100 +++ openssh-7.4p1/debian/.git-dpm 2017-10-06 20:03:26.0 +0100 @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -1fbd56e33d641c08a8f573406cf27f9adf667763 -1fbd56e33d641c08a8f573406cf27f9adf667763 +39d60bbd309be74d337685c2da524233652513f4 +39d60bbd309be74d337685c2da524233652513f4 971a7653746a6972b907dfe0ce139c06e4a6f482 971a7653746a6972b907dfe0ce139c06e4a6f482 openssh_7.4p1.orig.tar.gz diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog --- openssh-7.4p1/debian/changelog 2017-06-18 01:11:26.0 +0100 +++ openssh-7.4p1/debian/changelog 2017-10-06 20:03:40.0 +0100 @@ -1,3 +1,15 @@ +openssh (1:7.4p1-10+deb9u2) stretch; urgency=medium + + * Test configuration before starting or reloading sshd under systemd +(closes: #865770). + * Adjust compatibility patterns for WinSCP to correctly identify versions +that implement only the legacy DH group exchange scheme (closes: +#877800). + * Make "--" before the hostname terminate argument processing after the +hostname too (closes: #873201). + + -- Colin Watson Fri, 06 Oct 2017 20:03:40 +0100 + openssh (1:7.4p1-10+deb9u1) stretch; urgency=medium * Fix incoming compression statistics (thanks, Russell Coker; closes: diff -Nru openssh-7.4p1/debian/openssh-server.ssh.service openssh-7.4p1/debian/openssh-server.ssh.service --- openssh-7.4p1/debian/openssh-server.ssh.service 2017-06-18 01:08:12.0 +0100 +++ openssh-7.4p1/debian/openssh-server.ssh.service 2017-10-06 20:03:26.0 +0100 @@ -5,7 +5,9 @@ [Service] EnvironmentFile=-/etc/default/ssh +ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS +ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure diff -Nru openssh-7.4p1/debian/patches/auth-log-verbosity.patch openssh-7.4p1/debian/patches/auth-log-verbosity.patch --- openssh-7.4p1/debian/patches/auth-log-verbosity.patch 2017-06-18 01:08:11.0 +0100 +++ openssh-7.4p1/debian/patches/auth-log-verbosity.patch 2017-10-06 20:03:26.0 +0100 @@ -18,7 +18,7 @@ index 57b49f7f..7eb87b35 100644 --- a/auth-options.c +++ b/auth-options.c -@@ -59,9 +59,20 @@ int forced_tun_device = -1; +@@ -59,8 +59,19 @@ int forced_tun_device = -1; /* "principals=" option. */ char *authorized_principals = NULL; @@ -28,17 +28,16 @@ + extern ServerOptions options; - void ++void +auth_start_parse_options(void) +{ + logged_from_hostip = 0; + logged_cert_hostip = 0; +} + -+void + void auth_clear_options(void) { - no_agent_forwarding_flag = 0; @@ -316,10 +327,13 @@ auth_parse_options(struct passwd *pw, char *opts, char *file, u_long linenum) /* FALLTHROUGH */ case 0: diff -Nru openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch --- openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch 1970-01-01 01:00:00.0 +0100 +++ openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch 2017-10-06 20:03:26.0 +0100 @@ -0,0 +1,63 @@
Bug#877897: RFS: wxmaxima/17.10.0-3
Package: sponsorship-requests Severity: normal Dear mentors, I am afraid this time I have made another bug in my package "wxmaxima" and therefore kindly ask you to sponsor another upload. * Package name: wxmaxima Version : 17.10.0-3 Upstream Author : Andrej Vopodivec * URL : http://andrejv.github.io/wxmaxima/ * License : GPL-2 Section : math It builds those binary packages: wxmaxima - GUI for the computer algebra system Maxima To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wxmaxima Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_17.10.0-2.dsc wxMaxima is a powerful graphical front-end for maxima, a program that does symbolic algebra. An example: (%i1) val:[ a=10, b=sqrt(2), c=5 ]; (val) [a=10,b=sqrt(2),c=5] (%i2) poly:y=a*x^2+b*x+c$ (%i3) solve(poly,x); (%o3) [x=-(sqrt(4*a*y-4*a*c+b^2)+b)/(2*a),x=(sqrt(4*a*y-4*a*c+b^2)-b)/(2*a)] (%i4) subst(y=0,%); (%o4) [x=-(sqrt(b^2-4*a*c)+b)/(2*a),x=(sqrt(b^2-4*a*c)-b)/(2*a)] (%i5) subst(val,%); (%o5) [x=-(3*sqrt(22)*%i+sqrt(2))/20,x=(3*sqrt(22)*%i-sqrt(2))/20] (%i6) rectform(float(%)); (%o6) [x=-0.7035623639735145*%i-0.07071067811865477,x=0.7035623639735145*%i-0.07071067811865477] Don't know why mentors.debian.net doesn't like my watchfile: uscan does. If anybody has an idea how to make it work for mentors, too, I will prepare a new wxMaxima package that fixes this. Changes since the last upload: Re-Added an accidentally-dropped dependency. Regards, Gunter Königsmann
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
Thanks for sharing! The Debian package builds fine. However, when trying to use cc65 to compile a project of mine, compilation fails with “include/general.h(4): Error: Include file `peekpoke.h' not found”. Using strace, I can see: read(4, "#ifndef GENERAL_H_\n#define GENER"..., 4096) = 1790 access("include/peekpoke.h", F_OK) = -1 ENOENT (No such file or directory) access("/build/cc65-cBYPC5/cc65-2.16/include/peekpoke.h", F_OK) = -1 ENOENT (No such file or directory) write(2, "include/general.h(4): Error: ", 29include/general.h(4): Error: ) = 29 write(2, "Include file `peekpoke.h' not fo"..., 35Include file `peekpoke.h' not found) = 35 So it seems like the import path is incorrect — it currently points into the temporary path in which sbuild placed the source when building the Debian package, while it should point to /usr/share/cc65/include. On Fri, Oct 6, 2017 at 9:21 PM, László Böszörményi (GCS) wrote: > On Fri, Oct 6, 2017 at 11:00 AM, Michael Stapelberg > wrote: >> Great! Thanks for letting us know, please keep us posted on the progress. > OK, you can download[1] and build the package for testing. > > Regards, > Laszlo/GCS > [1] dget -x http://www.barcikacomp.hu/gcs/cc65_2.16-1.dsc -- Best regards, Michael
Bug#868157: heimdal-kdc: Crashes periodically (bad error handling?)
FWIW, this appears to be a known problem, as per this thread: http://www.h5l.org/pipermail/heimdal-discuss/2017-August/000259.html
Bug#877891: wxmaxima: should depend on maxima
On 06.10.2017 21:07, Daniel Serpell wrote: > Package: wxmaxima > Version: 17.10.0-1 > Severity: important > > Hi, > > New wxmaxima version no longer depends on maxima, so it was uninstalled > on upgrade, making the package unusable. > > Installing maxima manually made it work again. > Thanks for the bug report! Seems like I dropped the dependency along with the minimum version (which I meant to drop). Will upload the fix to debian mentors in a moment. Kind regards, Gunter.
Bug#877896: certspotter: FTBFS on mips{,el}
Source: certspotter Version: 0.5-1 Severity: serious Justification: fails to build from source (but built successfully in the past) certspotter FTBFS on the mips and mipsel buildds with no useful error message: > dh_auto_build: go install > -gcflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" > -asmflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" -v -p 4 > software.sslmate.com/src/certspotter software.sslmate.com/src/certspotter/cmd > software.sslmate.com/src/certspotter/cmd/certspotter > software.sslmate.com/src/certspotter/cmd/ctparsewatch > software.sslmate.com/src/certspotter/cmd/submitct > software.sslmate.com/src/certspotter/ct > software.sslmate.com/src/certspotter/ct/client returned exit code 1 > debian/rules:4: recipe for target 'build-arch' failed > make: *** [build-arch] Error 1 Cheers, Julien
Bug#862058: python-debian: required dependency on python-apt
Control: reopen -1 Control: tags -1 + patch Hi Stuart, On Sun, Sep 10, 2017 at 01:47:22AM +1000, Stuart Prescott wrote: > That iter_paragraphs works with compressed indexes at all is somewhat > accidental. I don't believe it is documented anywhere that this is a > supported > use of iter_paragraphs. (But it's rather handy that it does work!) In fact, > the documentation says that iter_paragraphs accepts: > > sequence: a string, or any any object that returns a line of > input each time, normally a file. > > (not a compressed file). > > Further, my feeling is that if a user chooses to break a Recommends, they get > what is coming to them and policy is quite clear about that. Thanks for your explanation, I agree with your conclusions. > As a user of the iter_paragraphs (and other!) functions, if you are in a > position to add to the docstrings of these functions so that this contract is > more clear to programmer, then that would be greatly appreciated. Building > some API docs with sphinx is something we should aim for but at present, > there > is not nearly enough documentation to make that worthwhile. I attached a patch that adds a couple lines of doc. In the process I realised there was a deprecated example with shared_storage in a README, which I took the opportunity to remove. Cheers, -- Matthieu From 86df0a5b86ec44f07e4fa624d33a5a002a479359 Mon Sep 17 00:00:00 2001 From: Matthieu Caneill Date: Fri, 6 Oct 2017 21:47:35 +0200 Subject: [PATCH] deb822: add clarifications for iter_paragraphs with compressed files --- README.deb822| 6 ++ lib/debian/deb822.py | 4 +++- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.deb822 b/README.deb822 index 89e7d64..4480c87 100644 --- a/README.deb822 +++ b/README.deb822 @@ -68,10 +68,8 @@ For example: print src['Package'], src['Version'] This method uses python-apt if available to parse the file, since it -significantly boosts performance. The downside, though, is that yielded -objects share storage, so they should never be kept accross iterations. -To prevent this behavior, pass a "shared_storage=False" keyword-argument -to the iter_paragraphs() function. +significantly boosts performance. If python-apt is not present and the +file is a compressed file, it must first be decompressed manually. Sample usage (TODO: Improve) diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py index 26f4b68..84af3c2 100644 --- a/lib/debian/deb822.py +++ b/lib/debian/deb822.py @@ -313,7 +313,9 @@ class Deb822(Deb822Dict): :param sequence: a string, or any any object that returns a line of input each time, normally a file. Alternately, sequence can -be a dict that contains the initial key-value pairs. +be a dict that contains the initial key-value pairs. When +python-apt is present, sequence can also be a compressed object, +for example a file object associated to something.gz. :param fields: if given, it is interpreted as a list of fields that should be parsed (the rest will be discarded). -- 2.8.1 signature.asc Description: PGP signature
Bug#868927: python-pybedtools FTBFS with more than one supported Python3 version
On Wed, Jul 19, 2017 at 10:47:09PM +0300, Adrian Bunk wrote: > On Wed, Jul 19, 2017 at 09:37:35PM +0200, Andreas Tille wrote: > >... > > I guess python-pysam is not yet build for Python3 3.6. > > That's #867017/#867018, which seems to require that you update > python-pysam to 0.11.2.2 That's done now. Unfortunately there is one remaining issue in the test suite: ... I: pybuild base:184: cd /build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build; python3.6 -m nose --attr '!url' .. E.S.. == ERROR: pybedtools.test.test1.test_issue_178 -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest self.test(*self.arg) File "/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build/pybedtools/test/test1.py", line 2108, in test_issue_178 pybedtools.contrib.bigwig.bam_to_bigwig(fn, genome='dm3', output='tmp.bw') File "/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build/pybedtools/contrib/bigwig.py", line 123, in bam_to_bigwig p = subprocess.Popen(cmds, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True) File "/usr/lib/python3.6/subprocess.py", line 709, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'bedGraphToBigWig': 'bedGraphToBigWig' -- Ran 491 tests in 12.192s FAILED (SKIP=1, errors=1) E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd /build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build; python3.6 -m nose --attr '!url' dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.6 3.5" returned exit code 13 ... Kind regards Andreas. -- http://fam-tille.de
Bug#875265: RFS: rednotebook/2.3-1 [ITP] [ITA] -- A cross-platform journal
Hi, New version upload. Your upload of the package 'rednotebook' to mentors.debian.net was successful. Others can now see it. The URL of your package is: https://mentors.debian.net/package/rednotebook The respective dsc file can be found at: https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.3-1.dsc Changes since last upload: rednotebook (2.3-1) unstable; urgency=low [ Jendrik Seipp ] * New upstream release * Compress backups. * Use newer txt2tags version 2.6 and reapply changes to obtain a GPL-2+ version. * Remove brittle PDF export. Please export to HTML and print to PDF with browser instead. * Remove intro page from export wizard. * Fix: image files were not found on Windows and Mac OS. * Print peak memory usage on Linux when program exits. * Hide tags panel completely by default instead of only minimizing it. * Update Debian files (@kathenas). -- Phil Wyett Fri, 06 Oct 2017 20:20:27 +0100 Regards Phil -- *** If this is a mailing list, I am subscribed, no need to CC me.*** Playing the game for the games sake. Web: https://kathenas.org GitLab: https://gitlab.com/kathenas Twitter: kathenasorg Instagram: kathenasorg GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A signature.asc Description: This is a digitally signed message part
Bug#864255: Status
This is just a status information: Currently this ITP is blocked by a licensing issue, vzlogger is GPL without a OpenSSL exception clause but has components linked to OpenSSL. I opened a Git issue to track a possible reclicense or rewrite of that portion of the code at https://github.com/volkszaehler/vzlogger/issues/331 -- PGP-encrypted mails preferred PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624 signature.asc Description: PGP signature
Bug#877745: gthumb: Recommends: gvfs-bin, which contains only deprecated tools
Hi Paul Wise, > Package: gthumb > Version: 3.5.2-2 > Severity: normal > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: gvfs-bin-deprecation > > This package Recommends: gvfs-bin, which contains only deprecated > tools. Please port it to the `gio` commands from libglib2.0-bin: > > $ grep deprecated, /usr/bin/gvfs-cat >> &2 echo "This tool has been deprecated, use '$replacement' instead." > $ grep replacement= /usr/bin/gvfs-* > /usr/bin/gvfs-cat:replacement="gio cat" > /usr/bin/gvfs-copy:replacement="gio copy" > /usr/bin/gvfs-info:replacement="gio info" > /usr/bin/gvfs-ls:replacement="gio list" > /usr/bin/gvfs-mime:replacement="gio mime" > /usr/bin/gvfs-mkdir:replacement="gio mkdir" > /usr/bin/gvfs-monitor-dir:replacement="gio monitor" > /usr/bin/gvfs-monitor-file:replacement="gio monitor" > /usr/bin/gvfs-mount:replacement="gio mount" > /usr/bin/gvfs-move:replacement="gio move" > /usr/bin/gvfs-open:replacement="gio open" > /usr/bin/gvfs-rename:replacement="gio rename" > /usr/bin/gvfs-rm:replacement="gio remove" > /usr/bin/gvfs-save:replacement="gio save" > /usr/bin/gvfs-set-attribute:replacement="gio set" > /usr/bin/gvfs-trash:replacement="gio trash" > /usr/bin/gvfs-tree:replacement="gio tree" > Gthumb does not use gvfs-bin. But I was the one who put gvfs-bin as "Recommends". I will update the package tomorrow. New version. Thanks! Regards, Herbert
Bug#877894: apticron: Encrypt apticron mails
Package: apticron Version: 1.1.61 Severity: wishlist Tags: patch Dear Tiago, as this is my first time sending a bug report I hope to do this the right way. As requested in your last mail I file this bug report. As you might remember the feature idea for apticron was to send the mails encrypted. I'll try to append the patch file. Best wishes, Matthias -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apticron depends on: ii apt1.4.7 ii bzip2 1.0.6-8.1 ii cron [cron-daemon] 3.0pl1-128+b1 ii debconf [debconf-2.0] 1.5.61 ii dpkg 1.18.24 ii mailutils [mailx] 1:3.1.1-1 ii ucf3.0036 Versions of packages apticron recommends: ii apt-listchanges 3.10 ii iproute2 4.9.0-1 apticron suggests no packages. -- debconf information excluded diff --git a/apticron b/apticron index 3edbca5..49c6df4 100755 --- a/apticron +++ b/apticron @@ -4,27 +4,41 @@ # implementations in Debian. Make sure we send proper headers, and a # text/plain content type. Mailx() { +# The statement msg="$(xargs --null echo)" will fail if the generated message +# is very long with xargs: argument line too long. +msg="$(xargs --null echo)" +if which gpg > /dev/null ; then +msg=$(echo "$msg" | gpg --trust-model always --batch --armor --encrypt --recipient $EMAIL --sign --passphrase $GPG_PASS_PHRASE) +if [ -z "$msg" ]; then +echo "GnuPG error. Could not encrypt message for $EMAIL. Exiting here." +exit 1 +fi +else +echo "GnuPG not installed. Exiting here." +exit 1 +fi + local MAILER="`readlink -e /usr/bin/mailx`" if [ x$MAILER = "x/usr/bin/heirloom-mailx" -o x$MAILER = "x/usr/bin/s-nail" ] then # heirloom-mailx creates correct headers, but needs help # if the terminal charset (LC_CTYPE) is no UTF-8 locale if [ -n "$CUSTOM_FROM" ] ; then - /usr/bin/mailx -S ttycharset=utf-8 -r "$CUSTOM_FROM" "$@" + echo "$msg" | /usr/bin/mailx -S ttycharset=utf-8 -r "$CUSTOM_FROM" "$@" else - /usr/bin/mailx -S ttycharset=utf-8 "$@" + echo "$msg" | /usr/bin/mailx -S ttycharset=utf-8 "$@" fi else # bsd-mailx/mailutils' mailx don't do character set # conversion, but do not support MIME either. if [ -n "$CUSTOM_FROM" ] ; then - /usr/bin/mailx -a "MIME-Version: 1.0" \ + echo "$msg" | /usr/bin/mailx -a "MIME-Version: 1.0" \ -a "Content-type: text/plain; charset=UTF-8" \ -a "Content-transfer-encoding: 8bit" \ -a "From: $CUSTOM_FROM" \ "$@" else - /usr/bin/mailx -a "MIME-Version: 1.0" \ + echo "$msg" | /usr/bin/mailx -a "MIME-Version: 1.0" \ -a "Content-type: text/plain; charset=UTF-8" \ -a "Content-transfer-encoding: 8bit" \ "$@"
Bug#877893: libpython3.5-stdlib: csv module: Sniffer shouldn't use '.*?' regex
Package: libpython3.5-stdlib Version: 3.5.4-2 Severity: normal Dear Maintainer, The csv module has a Sniffer class to try and detect the dialect used by a given csv file. To do so, at some point (in the method _guess_quote_and_delimiter), it runs several regular expressions on the data provided. Unfortunately, the regex are written such that the search time might grow quadratically with the size of the input when there is no match. For instance on the data: 1234,"foobar" 1234,"foobar" ... 1 lines like this The first regex, roughly simplified to r',".*?",' can take several seconds on 1 lines, growing like the square of the number of lines. To avoid this, I might suggest preventing the .*? to match an unescaped and un-doubled quote. Best regards, Celelibi -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpython3.5-stdlib depends on: ii libbz2-1.01.0.6-8.1 ii libc6 2.24-17 ii libdb5.3 5.3.28-13.1 ii liblzma5 5.2.2-1.3 ii libmpdec2 2.4.2-1 ii libncursesw5 6.0+20170902-1 ii libpython3.5-minimal 3.5.4-2 ii libreadline7 7.0-3 ii libsqlite3-0 3.20.1-1 ii libtinfo5 6.0+20170902-1 ii mime-support 3.60 libpython3.5-stdlib recommends no packages. libpython3.5-stdlib suggests no packages. -- no debconf information
Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env
On Fri, Oct 6, 2017 at 11:00 AM, Michael Stapelberg wrote: > Great! Thanks for letting us know, please keep us posted on the progress. OK, you can download[1] and build the package for testing. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/cc65_2.16-1.dsc
Bug#764730: dh_systemd_start: un-escapes - in unit/directory names
Control: tags -1 moreinfo On Fri, 10 Oct 2014 18:21:34 +0200 Bernd Zeimetz wrote: > On 10/10/2014 06:14 PM, Michael Biebl wrote: > > Do you have an example where this actually is a practical issue and not > > just a theoretical one? I.e, which package makes use escaped unit names? > > > > https://github.com/bzed/pkg-open-vm-tools/commit/1130d9e91b696f1a364ce6a73b84d2a2d41fcc1f > > just not uploaded yeat because of this and other systemd-related issues... > (which are not a bug in systemd, just an annoying thing). > > > > -- > Mit freundlichen Grüßen > > > Bernd Zeimetz > Systems Engineer > Debian Developer > > [...] Hi Bernd, I may have accidentally fixed as a side effect of another change in debhelper/10.7. Can you please check whether this bug has been fixed in 10.7 (or later)? Thanks, ~Niels
Bug#877892: docker.io is not installable, missing dependency on containerd
Source: docker.io Version: docker.io is not installable. Severity: normal Dear Maintainer, On up to date debian unstable, docker.io is not installable. The following information may help to resolve the situation: The following packages have unmet dependencies: docker.io : Depends: containerd (>= 0.2.3+git20170126.85.aa8187d~ds1~) but it is not going to be installed Depends: runc (>= 1.0.0~rc2+git20170201.133.9df8b30~) but it is not going to be installed E: Unable to correct problems, you have held broken packages. containerd is available, but its version is $ apt-cache show containerd|grep Version Version: 0.2.3+git20170126.85.aa8187d~ds1-2 Thanks, Abhijit -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#631806: This is almost certainly obsolete
I cannot reproduce this even with python-m2crypto in Debian/stretch (that's 0.24.0 from 2016-03-21). The last version where I could reproduce it is on my RHEL-7 (0.21.1 from 2011-01- 15). If you can reproduce the bug with version of M2Crypto more recent than the last year, I would be interested in the bug report upstream (https://gitlab.com/m2crypto/m2crypto/issues/new ). Thank you, Matěj
Bug#877891: wxmaxima: should depend on maxima
Package: wxmaxima Version: 17.10.0-1 Severity: important Hi, New wxmaxima version no longer depends on maxima, so it was uninstalled on upgrade, making the package unusable. Installing maxima manually made it work again. Thanks, Daniel. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wxmaxima depends on: ii ibus-gtk3 1.5.14-3 ii libc6 2.24-17 ii libgcc1 1:7.2.0-8 ii libstdc++67.2.0-8 ii libwxbase3.0-0v5 3.0.3.1+dfsg2-1 ii libwxgtk3.0-0v5 3.0.3.1+dfsg2-1 Versions of packages wxmaxima recommends: ii maxima-doc 5.40.0-3 Versions of packages wxmaxima suggests: ii fonts-jsmath 0.090709+0-3 pn texlive-latex-extra -- no debconf information
Bug#877583: [octocatalog-diff] Patch for missing scripts
Control: tag -1 + patch Here is a patch. Regards Mathieu Parent From 30ca15b5ff90d3871d34a12f2c6f9cec378e2dcc Mon Sep 17 00:00:00 2001 From: Mathieu Parent Date: Fri, 6 Oct 2017 20:51:52 +0200 Subject: [PATCH] Install scripts (Closes: #877583) --- debian/rules | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rules b/debian/rules index ad8762e..68456dc 100755 --- a/debian/rules +++ b/debian/rules @@ -12,6 +12,8 @@ override_dh_auto_install: dh_auto_install rm debian/octocatalog-diff/usr/lib/ruby/vendor_ruby/octocatalog-diff/external/pson/LICENSE sed -e 's/@VERSION@/$(VERSION)/' debian/version.rb > debian/octocatalog-diff/usr/lib/ruby/vendor_ruby/octocatalog-diff/version.rb + mkdir -p debian/octocatalog-diff/usr/lib/ruby/scripts + cp -a scripts/* debian/octocatalog-diff/usr/lib/ruby/scripts/ override_dh_installdocs: dh_installdocs -Xdev/ -XCHANGELOG.md -- 2.14.2
Bug#871619: [Pkg-zfsonlinux-devel] Bug#871619: Bug#871619: Packaging
On Fri, 6 Oct 2017 08:49:51 +0200 Dmitry Galenko wrote: > I successful build deb packages from upstream repo, for kernel 4.10 > (custom) without any changes with this instruction: > > [snip] this is not a good idea for production use IMHO - those converted packages using alien lack all of the integration into Debian proper (including missing all the systemd service stuff, among other things)..
Bug#871619: Packaging
> Aron Xu hat am 6. Oktober 2017 um 18:19 geschrieben: > > > Hi, > > On Fri, Oct 6, 2017 at 4:59 PM, Petter Reinholdtsen wrote: > > > > [Antonio Russo] > >> How can I help out the packaging team on this? Who should I email? > > > > The best way to help is to continue contributing and participating on > > the team mailing list and IRC channel. > > > > Aron Xu has been most active with maintenance, and I hope he can comment > > on how you best can contribute. I am not competent do to so. :) > > > > Any project admin on > > https://alioth.debian.org/projects/pkg-zfsonlinux/ > can grant > > access, ie Aron, Liang and Carlos. > > > > CC to Aron, and email to the bts also go to the project mailing list. > > > > I've started to update the package to 0.7.2 release and it appears > there are some build system changes that installs quite some files > into non-FHS compliant paths, and possibly a new package (could be > "zfs-tests") is needed. If you are eager to help, please start from > these changes and my latest work is available on alioth git. > > Regards, > Aron > did you see my WIP branch on github, linked earlier here (and also separately on pkg-zfsonlinux-de...@lists.alioth.debian.org)[1,2]? I already did most of the work (including splitting out zfs-test) except for updating debian/copyright.. note that I merged the actual upstream tags and not the upstream release tar balls, so you probably only want to take a closer look at commits touching debian/ ;) I have been running this branch (recently with the addition of upstream PR#6616[3]) for quite some time on my personal machines (Sid and Stretch), and have been testing a variant of it with a 4.13 kernel at work as well - all without any problems so far (except for the send/receive incompatibility with 0.6.5, for which I made the PR ;)) the only other point up for discussion besides splitting out zfs-test was whether the zfs and zpool binaries should move to /bin instead of /sbin, as they are now usable by unprivileged users for certain read-only operations.. I would be glad to assist in any future work here, both for the 0.7.2 release as well as further packaging (I am responsible for most of the downstream ZFS packaging in Proxmox VE, which is based on Debian - so I am familiar with both ZoL and Debian packaging ;)). if you have any questions about my branch or want to discuss stuff, just drop me an e-mail (here, on-list or directly) or catch me on IRC (f_g on OFTC and freenode) 1: https://github.com/Fabian-Gruenbichler/zfs/commits/debian/wip-0.7 2: https://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/2017-August/001196.html 3: https://github.com/zfsonlinux/zfs/pull/6616
Bug#877766: lintian: more false positives in copyright-year-in-future
I see what you mean. Point taken :) On Fri, Oct 6, 2017 at 8:43 PM Chris Lamb wrote: > Hi Mattia, > > > Dunno if this is the case, but would be possible to at least keep it for > > some cases > […] > > Whilst this is certainly possible I just can't shake the feeling that > this tag isn't actually finding "real" bugs in packages worth of the > investment. > > Sure, a typo of 2117 instead of 2017 is objectively "wrong" but whilst > I am not a lawyer (I just play one on TV, etc. etc.) no court anywhere > in the world is going to rule against someone on the basis of such an > obvious typo. > > Thus, I think the Lintian developers' precious hours are better spent > elsewhere and not playing whack-a-mole with this tag, and that's not > taking into consideration the time or annoyance this tag can cause or > has already caused regular developers. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` la...@debian.org / chris-lamb.co.uk >`- >
Bug#717675: This has been fixed upstream
This has been already fixed by the upstream commit 79032181 in the release 0.26.0 from 2017-03-25. Happy hacking! Matěj signature.asc Description: This is a digitally signed message part
Bug#877766: lintian: more false positives in copyright-year-in-future
Hi Mattia, > Dunno if this is the case, but would be possible to at least keep it for > some cases […] Whilst this is certainly possible I just can't shake the feeling that this tag isn't actually finding "real" bugs in packages worth of the investment. Sure, a typo of 2117 instead of 2017 is objectively "wrong" but whilst I am not a lawyer (I just play one on TV, etc. etc.) no court anywhere in the world is going to rule against someone on the basis of such an obvious typo. Thus, I think the Lintian developers' precious hours are better spent elsewhere and not playing whack-a-mole with this tag, and that's not taking into consideration the time or annoyance this tag can cause or has already caused regular developers. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#877766: lintian: more false positives in copyright-year-in-future
Hi Chris, On Fri, Oct 06, 2017 at 11:00:15AM +0100, Chris Lamb wrote: > "Fixed" in Git: > > > https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b82460be905f860ef0b878b4b927c29ae9535566 Dunno if this is the case, but would be possible to at least keep it for some cases where the amount of fpos would be way lower? I'm thinking about checking on machine-parsable d/copyright, and only for the Copyright fields, and even there only the first chars of the field. -- 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#877421: lintian: privacy-breach-donation check should ignore URLs in comments
tags 877421 + pending thanks Fixed in Git: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=077f99c547c9e79b40b625e8d60aea05258637b7 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#859225: M2Crypto na OpenSSL 1.1.0
Just to say, that M2Crypto since 0.26.2 (current release is 0.27.0) officially supports OpenSSL 1.1.0 API, no compat- libraries are needed anymore. Best, Matěj Cepl (upstream maintainer of M2Crypto) signature.asc Description: This is a digitally signed message part
Bug#877890: qemu: CVE-2017-15038: 9p: virtfs: information disclosure when reading extended attributes
Source: qemu Version: 1:2.10.0+dfsg-1 Severity: important Tags: patch security upstream Hi, the following vulnerability was published for qemu. CVE-2017-15038[0]: |Qemu: 9p: virtfs: information disclosure when reading extended |attributes If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-15038 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15038 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1499110 [2] https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00729.html [3] http://www.openwall.com/lists/oss-security/2017/10/06/1 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#789594: does this problem still exist?
Hi Nigel, while browsing through older bugs of apcupsd I wonder whether this bug report is still valid. Do you still have problems with apcaccess contacting your apcupsd? Thorsten
Bug#752195: does this problem still exist?
Hi, while browsing through older bugs of apcupsd I wonder whether your bug report is still valid. Do you still have problems with your Eaton 3s? Thorsten
Bug#876667: RFS: pragha/1.3.3-1
Hello Gabriel, On Tue, Sep 26, 2017 at 09:05:58PM +0200, Lukas Schwaighofer wrote: > Hi Gabriel, > > it seems you are getting the knack of it quickly :) . I don't have > any additional feedback. I hope you're able to find a sponsor soon. I am just doing a final review for the sponsor, and I found something that annoys every developer, it seems that pragha does not re-builds after an initial build. It builds fine for the very first time, but if you try to re-build, the directory stays dirty and does not allow the package to be rebuilt: This is what I tried: $ get -x https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-1.dsc $ cd pragha-1.3.3 $ debuild ; debuild You are going to see something like: dpkg-source: error: cannot represent change to po/bg.gmo: binary file contents changed dpkg-source: error: add po/bg.gmo in debian/source/include-binaries if you want to store the modified binary in the debian tarball This means that your clean rules is not cleaning everything that was generated during the build process. Thank you and sorry for the delay, Breno
Bug#877806: pulseaudio: Speaker silent after updating eeepc to Debian 9
On 5.10.17, Felipe Sateler wrote: > > Note: > > Before the update, pavucontrol listed 3 outputs: > > audio, speaker, and headphone. "audio" worked. > > > > After the update, the "audio" port is missing on the list. > This suggests that relevant change is in the kernel. Did you try > booting with the old kernel? Booting with 3.16 did not make a change. GM
Bug#877889: RM: pbnj -- RoQA; thoroughly buggy, dead upstream, popcon 18/4
Package: ftp.debian.org Severity: normal Hi! "pbnj" has been dead upstream in a decade, and hasn't seen a maintainer upload that long as well. There was a NMU in meantime, but apparently only to fix FTBFS, without testing the functionality. When preparing a QA upload for a seemingly trivial bug, I've refreshed the packaging, which happened to auto-enable the testsuite. And all hell broke loose. Some of the fixes are simple (such as s/ipv4_sort/addr_sort/ when using Nmap::Parser), some are not -- but fixing everything to even let it build (without sweeping the testsuite under the carpet) is way above the amount of damn I give for a popcon vote:4 package. Thus, let's let it follow the upstream project into the great bit bucket in the sky.
Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable
Package: cups-bsd Version: 2.2.4-7 Severity: normal File: /usr/bin/lpq lpq and lp are no longer paying attention to the PRINTER environment variable. (The cups(1) manpage says that PRINTER is used except for setuid binaries. But lpq and lp are not setuid.) Here is a commented log with lpq: $ lpq lj400 is ready /* my default destination */ no entries $ PRINTER=mh371 printenv PRINTER mh371 /* to show that the environment variable inherits */ $ PRINTER=mh371 lpq lj400 is ready /* but lpq ignores it */ no entries $ lpq -Pmh371 mh371 is ready /* to show that mh371 is a known destination */ no entries And for lp: $ PRINTER=mh371 lp /usr/share/hplip/data/ps/testpage.ps.gz request id is lj400-2890 (1 file(s)) It went to the default destination despite the environment setting. Here is my /etc/cups/lpoptions: Default lj400 fitplot=true PageSize=Letter sides=two-sided-long-edge Dest lj400/gs fitplot=true PageSize=Letter pdftops-renderer=gs sides=two-sided-long-edge Dest mh235 fitplot=true PageSize=Letter sides=two-sided-long-edge Dest mh271 fitplot=true PageSize=Letter sides=two-sided-long-edge Dest mh271/duplex fitplot=true PageSize=Letter sides=two-sided-long-edge Dest mh271/saver fitplot=true number-up=2 PageSize=Letter sides=two-sided-long-edge Dest mh371 PageSize=Letter sides=two-sided-long-edge Dest mitx duplex=duplexnotumble Dest psc outputorder=reverse PageSize=Letter PrintoutMode=High -Sanjoy -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-bsd depends on: ii cups-client 2.2.4-7 ii cups-common 2.2.4-7 ii debconf 1.5.63 ii libc62.24-17 ii libcups2 2.2.4-7 cups-bsd recommends no packages. Versions of packages cups-bsd suggests: ii cups 2.2.4-7 ii update-inetd 4.44 -- debconf information: cups-bsd/setuplpd: false --
Bug#877887: please package latest upstream version (1.14.x)
Source: koji Version: 1.10.0-1 Severity: wishlist Ohai, https://pagure.io/koji/releases lists 1.14.0 as latest koji release, please update the packaging :) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#877886: fedorahosted.org is deprecated, koji upstream is now at https://pagure.io/koji
Source: koji Severity: wishlist please update d/control, d/copyright and d/watch accordignly :) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#877885: sssd: CVE-2017-12173: unsanitized input when searching in local cache database
Source: sssd Severity: important Tags: upstream security Hi, the following vulnerability was published for sssd. CVE-2017-12173[0]: unsanitized input when searching in local cache database If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2017-12173 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12173 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1498173 Please adjust the affected versions in the BTS as needed, and unfortuantely at time of writing, I have not found any furhter information on the issue than what is written in [1]. Any ideas? Is there an upstream issue to track? Regards, Salvatore
Bug#877884: Missing CLDR data from http://www.unicode.org/Public/
Package: unicode-data Version: 10.0.0-3 Severity: wishlist http://www.unicode.org/Public/ has a lot of data. Data under emoji is included in the unicode-data package but data under cldr is not. It will be nice cldr data is also available. Background: I actually needed emoji data and some parts of cldr data under the /usr/share/unocode directory to update ibus program. I understand emoji is mentioned in but cldr is not mentioned in http://www.unicode.org/versions/Unicode10.0.0/ But http://www.unicode.org/ has a prominent link to http://cldr.unicode.org/index so I do expect this data is also included or coordinated with this package. Fedora seems to create another rpm https://github.com/fujiwarat/cldr-emoji-annotation which looks like coming from the unicode cldr data but not all of them. He installs part of idata from the zip file under /usr/share/unocode/cldr/common/annotations /usr/share/unocode/cldr/common/annotationsDerived The data used is http://www.unicode.org/Public/cldr/31.0.1/cldr-common-31.0.1.zip http://www.unicode.org/Public/cldr/31.0.1/core.zip (These seem to be the same file) It will be nice you also include or package these zip files in http://www.unicode.org/Public/cldr/31.0.1/ or its new version. Anyway, this data archive is huge. Unless careful coordination is done, we may end up lots of duplicated data. I am not quite sure how these should be packaged for Debian. I guess unicode-data maintainer has a better idea, So i am filing this bug report. Osamu -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#841623: python-pyrax: FTBFS: Forbidden: 'novaclient.v2.client.Client' is not designed to be initialized directly. It is inner class of novaclient. You should use 'novaclient.client.Client' instead
Hi, fixed in git, but i got new build problems with python-novaclient and it's dependencies python-keyring and dbus inside the pbuilder chroot. == ERROR: tests.unit.test_image (unittest.loader.ModuleImportFailure) -- ImportError: Failed to import test module: tests.unit.test_image Traceback (most recent call last): File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests module = self._get_module_from_name(name) File "/usr/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name __import__(name) File "tests/unit/test_image.py", line 13, in import pyrax File "pyrax/__init__.py", line 42, in import keyring File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6, in from .core import (set_keyring, get_keyring, set_password, get_password, File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 148, in init_backend() File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 64, in init_backend keyrings = filter(limit, backend.get_all_keyring()) File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 20, in wrapper func.always_returns = func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 191, in get_all_keyring exceptions=TypeError)) File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 29, in suppress_exceptions for callable in callables: File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 183, in is_class_viable keyring_cls.priority File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py", line 22, in __get__ return self.fget.__get__(None, owner)() File "/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py", line 30, in priority bus = secretstorage.dbus_init() File "/usr/lib/python2.7/dist-packages/secretstorage/__init__.py", line 47, in dbus_init return dbus.SessionBus() File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__ mainloop=mainloop) File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /run/user/1000/bus: No such file or directory Regards Sascha signature.asc Description: OpenPGP digital signature
Bug#827395: [privacy] not as 'secure by default'
> Narcis Garcia writes: > Note: trek.eu.org link provided by Trek is not working. I’ve just checked and [1] does work for me. (Note though that ‘www’ has to be there.) An archived copy [2] is also available. [1] http://www.trek.eu.org/text/firefox-tuning.html [2] https://web.archive.org/web/20170411151300/http://www.trek.eu.org/text/firefox-tuning.html > Why a non-private browsing? User activity should be assumed as > private by default. Or at least there should be an easier (and more prominently presented) way for the user to opt out. > Proposed defaults: > browser.newtabpage.directory.ping = "" > browser.newtabpage.directory.source = "" Personally, I’ve disabled all the ‘safebrowsing’, ‘update’, and similar options I could find. Also, just to be sure, I’ve uniformly replaced nearly every single URI in prefs.js like: user_pref("browser.safebrowsing.provider.mozilla.updateURL", "http://browser.safebrowsing.provider.mozilla.updateurl.unwanted.nowhere.invalid/";); Now I can refer to my HTTP proxy logs for the possible attempts to disclose my use of Firefox to third parties (like my ISP, employer, and whatever the entity it tries to connect to.) Which seem to be surprisingly few (and the last one below is due to xul-ext-noscript, not Firefox proper): browser.newtabpage.directory.source browser.safebrowsing.provider.mozilla.updateurl browser.search.geoip.url extensions.blocklist.url noscript.abe.wanipcheckurl Can at least the ‘safebrowsing’ one please be fixed to respect the whatever ‘browser.safebrowsing.*.enabled = false’ setting applicable? Can there be also options to cleanly disable the ‘newtabpage.directory’ and ‘search.geoip’ functions as well? TIA. > captivedetect.canonicalURL = "" > app.update.url = "" > browser.safebrowsing.downloads.remote.url = "" […] > browser.safebrowsing.reportPhishURL = "" > browser.search.geoSpecificDefaults.url = "" > browser.search.geoip.url = "" I think it should also include browser.search.suggest.enabled = false, which appears rather important as “search suggestions” result in even the partial input being communicated to a remote party. (Which may even be a genuinely sensitive information – like one’s password – by the way of pure accident.) It’s basically Firefox’ very own remote keyboard logger! > browser.tabs.crashReporting.sendReport = false > datareporting.healthreport.service.enabled = false > datareporting.healthreport.uploadEnabled = false > datareporting.policy.dataSubmissionEnabled = false > security.ssl.errorReporting.enabled = false > security.ssl.errorReporting.url = "" > security.ssl.errorReporting.automatic = "" > browser.startup.homepage = "https://start.duckduckgo.com/"; I believe it should rather be about:blank, file:/, or something like that – not requiring any network access whatsoever. > devtools.gcli.imgurUploadURL = "" […] > devtools.webide.templatesURL = "" > experiments.manifest.uri = "" > geo.wifi.uri = "" > identity.mobilepromo.android = "" > identity.mobilepromo.ios = "" > security.ssl.errorReporting.url = "" > toolkit.telemetry.server = "" > webextensions.storage.sync.enabled = false -- FSF associate member #7257 http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB
Bug#871648: qemu-system-x86: /usr/bin/qemu-system-i386 eats slowly but surely all the Dom0 memory
Michael Tokarev: > This bug has been fixed by the last security update of qemu. > > Thanks, > > /mjt Shall we close it then? The "Closes:" in the changelog somehow did not do it...
Bug#877883: [openblas] cblas_* takes double* instead of void* for complex arrays
Package: openblas Version: 0.2.19-3 Severity: wishlist Dear Maintainer, OpenBLAS in version 0.2.19-3 currently installed on Debian Stretch as well as the version 0.2.20+ds-4 in Testing declares the cblas_*() as taking double* instead of void* for complex values. As an example, it declares cblas_zdscal as void cblas_zdscal(OPENBLAS_CONST blasint N, OPENBLAS_CONST double alpha, double *X, OPENBLAS_CONST blasint incX); This function takes an array of complex numbers X and scales them by the real value alpha. In contrast to this, all other packages in Debian as well as the Intel MKL define cblas_zdscal as taking a void* for X, i.e.: void cblas_zdscal(const int N, const double alpha, void *X, const int incX); See e.g. https://codesearch.debian.net/search?q=cblas_zdscal&perpkg=1 or https://software.intel.com/en-us/mkl-developer-reference-c-cblas-scal or http://www.netlib.org/blas/cblas.h The same difference applies to the cblas_zscal() function and all others: $ dpkg -S /usr/include/cblas.h; dpkg -S /usr/include/openblas/cblas.h; grep zscal /usr/include/openblas/cblas.h /usr/include/cblas.h libblas-dev: /usr/include/cblas.h libopenblas-dev: /usr/include/openblas/cblas.h /usr/include/openblas/cblas.h:void cblas_zscal(OPENBLAS_CONST blasint N, OPENBLAS_CONST double *alpha, double *X, OPENBLAS_CONST blasint incX); /usr/include/cblas.h:void cblas_zscal(const int N, const void *alpha, void *X, const int incX); I have only noticed the issue now as cblas.h has become part of the alternatives system and is currently directing to the OpenBLAS version in testing. In Stretch, if also libblas-dev is installed, its cblas.h is used and the difference hence hidden away. I suspect that this problem is not more widespread because people tend to cast their arguments to (void*) explicitly, but the conversion std::complex* => void* => double* is probably actually undefined… There was also some discussion in 2013, but it seemed to go nowhere: http://comments.gmane.org/gmane.comp.lib.openblas.general/192 I would be very thankful if there was some way to avoid the explicit casts to (void*) in calls specifically for OpenBLAS. Best wishes, Claudius --- System information. --- Architecture: Kernel: Linux 4.9.0-3-amd64 Debian Release: 9.1 990 stable security.debian.org 990 stable ftp.de.debian.org 500 unstableftp.de.debian.org 500 stable repo.skype.com --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. pgpuf13nCNRtX.pgp Description: OpenPGP digital signature
Bug#835189: python-pyrax: FTBFS (failing tests)
Hi, fixed in git, but i got new buildproblems with python-novaclient and it's dependencies python-keyring and dbus inside the pbuilder chroot. == ERROR: tests.unit.test_image (unittest.loader.ModuleImportFailure) -- ImportError: Failed to import test module: tests.unit.test_image Traceback (most recent call last): File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests module = self._get_module_from_name(name) File "/usr/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name __import__(name) File "tests/unit/test_image.py", line 13, in import pyrax File "pyrax/__init__.py", line 42, in import keyring File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6, in from .core import (set_keyring, get_keyring, set_password, get_password, File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 148, in init_backend() File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 64, in init_backend keyrings = filter(limit, backend.get_all_keyring()) File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 20, in wrapper func.always_returns = func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 191, in get_all_keyring exceptions=TypeError)) File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line 29, in suppress_exceptions for callable in callables: File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 183, in is_class_viable keyring_cls.priority File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py", line 22, in __get__ return self.fget.__get__(None, owner)() File "/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py", line 30, in priority bus = secretstorage.dbus_init() File "/usr/lib/python2.7/dist-packages/secretstorage/__init__.py", line 47, in dbus_init return dbus.SessionBus() File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__ mainloop=mainloop) File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /run/user/1000/bus: No such file or directory Regards Sascha Am 18.01.2017 um 17:10 schrieb Sascha Girrulat: > thx for the update. I try to handle it asap. I'm only short of time at > the moment. > > Regards > Sascha > > Am 17.01.2017 um 01:50 schrieb Santiago Vila: >> retitle 835189 python-pyrax: FTBFS (failing tests) >> thanks >> >> Hi. >> >> After building this package many times today, it always fail >> and not just sometimes, so I'm retitling accordingly. >> >> As a summary, I see that the following tests always fail: >> >> ERROR: test_set_http_debug (tests.unit.test_module.PyraxInitTest) >> ERROR: test_connect_to_cloudservers (tests.unit.test_module.PyraxInitTest) >> >> and the following one fails approximately 70% of the time: >> >> ERROR: test_rax_endpoints (tests.unit.test_identity.IdentityTest) >> >> [ The first two failing tests are the ones reported by Lucas Nussbaum >> in Bug #841623 ]. >> >> Thanks. >> > signature.asc Description: OpenPGP digital signature
Bug#871619: Packaging
Hi, On Fri, Oct 6, 2017 at 4:59 PM, Petter Reinholdtsen wrote: > > [Antonio Russo] >> How can I help out the packaging team on this? Who should I email? > > The best way to help is to continue contributing and participating on > the team mailing list and IRC channel. > > Aron Xu has been most active with maintenance, and I hope he can comment > on how you best can contribute. I am not competent do to so. :) > > Any project admin on > https://alioth.debian.org/projects/pkg-zfsonlinux/ > can grant > access, ie Aron, Liang and Carlos. > > CC to Aron, and email to the bts also go to the project mailing list. > I've started to update the package to 0.7.2 release and it appears there are some build system changes that installs quite some files into non-FHS compliant paths, and possibly a new package (could be "zfs-tests") is needed. If you are eager to help, please start from these changes and my latest work is available on alioth git. Regards, Aron
Bug#877865: IMAP access to bug reports
On 06/10/17 17:35, Don Armstrong wrote: > On Fri, 06 Oct 2017, Daniel Pocock wrote: >> Package: bugs.debian.org >> Severity: wishlist >> >> Bug reports can currently be accessed in mbox format >> >> Has anybody looked at ways to provide read-only IMAP access to the bug >> reports or another API that mail clients like Thunderbird could use? > Hrm; I've not, but that sounds interesting. I'd certainly consider > patches which enabled such a thing. [Though I'd think that having > thunderbird open a mailbox on local disk would be pretty easy?] > > I did have thoughts about making a more-maildir style storage for mail, > but it was really low on my priority list. > People could rsync a Maildir very easily too
Bug#877882: RM: r-cran-boolnet [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available
Package: ftp.debian.org Severity: normal $ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-boolnet W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: r-cran-boolnet |2.1.3-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386 Maintainer: Debian Med Packaging Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. Andreas
Bug#877881: RM: r-cran-lexrankr [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available
Package: ftp.debian.org Severity: normal $ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-lexrankr W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: r-cran-lexrankr |0.4.0-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386 Maintainer: Debian Med Packaging Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. Andreas
Bug#877880: RM: r-cran-phangorn [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available
Package: ftp.debian.org Severity: normal $ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-phangorn W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: r-cran-phangorn | 1.99.14-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386 r-cran-phangorn |2.2.0-2 | source Maintainer: Debian Med Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Build-Depends: r-cran-treescape: r-cran-phangorn (>= 2.0.3) Dependency problem found. r-cran-treescape is already not built on these architectures. Andreas
Bug#871690: libglib2.0-0: gtk filechooser places populates with *all* filesystems
Hello I find this: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1701780 At the end it says that the fix is in glib2.0 - 2.54.1-1ubuntu1. I installed libglib2.0-0, libglib2.0-bin and libglib2.0-data 2.54.1-1 from sid (i'm in testing) and that fixed my problem!! So, for me, you can close this bug report. Many thanks for all. Greetings. 2017/09/10 13:11 (ig.) eguna, Michael Biebl (e)k idatzi zuen: > Am 10.09.2017 um 12:15 schrieb Martintxo: > > > By other side, I need to inform that I'm not using any desktop environment, > > I use a plain Icewm, and not use nor udisks, nor gvfs. If that's a problem, > > you can forget this report, but I think that this is a important issue... > > > > I guess no-one of the GNOME maintainers actually uses glib without > gvfs/udisks. Most likely your issue would be solved if you use those > packages. > So if you want to see this addressed I guess it's up to you to further > investigate this on your own, i.e. which changes in glib caused this new > behaviour > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles. proiektu jasangaitzei erantzun juridiko-teknikoa. http://www.fundacionsustrai.org http://www.sustraierakuntza.org
Bug#877878: ITP: mailman3-suite -- Django project integrating Mailman3 Postorius and HyperKitty
Package: wnpp Severity: wishlist Owner: Jonas Meurer * Package name: mailman3-suite Version : 0+20170523 Upstream Author : Free Software Foundation, Inc * URL : https://gitlab.com/mailman/mailman-suite * License : GPL-3 Programming Lang: Python Description : Django project integrating Mailman3 Postorius and HyperKitty This django web application provides the Mailman3 Postorius web interface and the HyperKitty mailinglist archiver integrated into one project and made available via uwsgi. This package will be maintained under the pkg-mailman umbrella. Cheers jonas
Bug#877879: RM: r-cran-igraph [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; B-D: r-cran-nmf not available
Package: ftp.debian.org Severity: normal $ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-igraph W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: r-cran-igraph |0.7.1-1 | source r-cran-igraph | 0.7.1-1+b1 | hurd-i386, kfreebsd-amd64, kfreebsd-i386 r-cran-igraph |1.1.2-2 | source Maintainer: Debian Med Packaging Team --- Reason --- -- Checking reverse dependencies... # Broken Depends: r-bioc-phyloseq: r-bioc-phyloseq r-cran-boolnet: r-cran-boolnet r-cran-lexrankr: r-cran-lexrankr r-cran-phangorn: r-cran-phangorn # Broken Build-Depends: r-bioc-phyloseq: r-cran-igraph r-cran-adegenet: r-cran-igraph r-cran-boolnet: r-cran-igraph r-cran-lexrankr: r-cran-igraph r-cran-phangorn: r-cran-igraph (>= 1.0) Dependency problem found. r-bioc-phyloseq is arch:all, will file RM requests for the others if needed. Andreas
Bug#877865: IMAP access to bug reports
On Fri, 06 Oct 2017, Daniel Pocock wrote: > Package: bugs.debian.org > Severity: wishlist > > Bug reports can currently be accessed in mbox format > > Has anybody looked at ways to provide read-only IMAP access to the bug > reports or another API that mail clients like Thunderbird could use? Hrm; I've not, but that sounds interesting. I'd certainly consider patches which enabled such a thing. [Though I'd think that having thunderbird open a mailbox on local disk would be pretty easy?] I did have thoughts about making a more-maildir style storage for mail, but it was really low on my priority list. -- Don Armstrong https://www.donarmstrong.com G: If we do happen to step on a mine, Sir, what do we do? EB: Normal procedure, Lieutenant, is to jump 200 feet in the air and scatter oneself over a wide area. -- Somewhere in No Man's Land, BA4
Bug#877877: devscripts: debchange manpage out of sync with help-text
Package: devscripts Version: 2.17.6+deb9u1 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, The manpage for the debchange script is out of sync with the help-text provided by it. Specifically, the --bpo argument description found in the manpage mentions "jessie-backports", while the help-text (correctly) mentions "stretch- backports". Thanks. - -- Package-specific info: - --- /etc/devscripts.conf --- - --- ~/.devscripts --- BTS_SMTP_HOST=ssmtp://mail.riseup.net DEBSIGN_KEYID=0B5A33B8A26D60109C509C6C83E33BD7D4DD4CA1 DEBUILD_LINTIAN=yes DEBUILD_LINTIAN_OPTS="--info --display-info --pedantic" - -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (900, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=fr_CA.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.18.24 ii libc6 2.24-11+deb9u1 ii libfile-homedir-perl 1.00-1 ii perl 5.24.1-3+deb9u2 ii python3 3.5.3-1 Versions of packages devscripts recommends: ii apt 1.4.7 ii at 3.1.20-3 ii curl7.52.1-5 ii dctrl-tools 2.24-2+b1 ii debian-keyring 2017.05.28 ii dput-ng [dput] 1.13 ii equivs 2.0.9+nmu1 ii fakeroot1.21-3.1 ii file1:5.30-1+deb9u1 ii gnupg 2.1.18-6 ii gnupg2 2.1.18-6 ii libdistro-info-perl 0.14 ii libdpkg-perl1.18.24 ii libencode-locale-perl 1.05-1 ii libgit-wrapper-perl 0.047-1 ii liblist-compare-perl0.53-1 ii liblwp-protocol-https-perl 6.06-2 ii libsoap-lite-perl 1.20-1 ii liburi-perl 1.71-1 ii libwww-perl 6.15-1 ii licensecheck3.0.29-1 ii lintian 2.5.53~bpo9+1 ii man-db 2.7.6.1-2 ii patch 2.7.5-1+b2 ii patchutils 0.3.4-2 ii python3-debian 0.1.30 ii python3-magic 1:5.30-1+deb9u1 ii sensible-utils 0.0.9 ii strace 4.15-2 ii unzip 6.0-21 ii wdiff 1.2.2-2 ii wget1.18-5 ii xz-utils5.2.2-1.2+b1 Versions of packages devscripts suggests: ii adequate 0.15.1 ii autopkgtest 4.4 pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20160123cvs-4 ii build-essential 12.3 pn check-all-the-things pn cvs-buildpackage pn devscripts-el pn diffoscope pn disorderfs pn dose-extra pn duck pn faketime ii gnuplot 5.0.5+dfsg1-6+deb9u1 ii gpgv 2.1.18-6 ii how-can-i-help 15 ii libauthen-sasl-perl 2.1600-1 ii libfile-desktopentry-perl0.22-1 ii libnet-smtps-perl0.04-1 pn libterm-size-perl ii libtimedate-perl 2.3000-2 pn libyaml-syck-perl pn mozilla-devscripts ii mutt 1.7.2-1 ii openssh-client [ssh-client] 1:7.4p1-10+deb9u1 ii piuparts 0.77 pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3-34 - -- no debconf information -BEGIN PGP SIGNATURE- iQJGBAEBCgAwFiEEC1ozuKJtYBCcUJxsg+M719TdTKEFAlnXoqcSHGplcm9tZUBy aXNldXAubmV0AAoJEIPjO9fU3Uyh1OgQAI08SZNqFMVKb1/fjohBQmJKkUWRoHvM 3qjKOxueaKgSLT9SveXMrsYSmqXVG3cGt0KNnHClP5EZvx2itJGELLhvET11dtfX IMWvwlPOVcZ+L8BuQ6BXMhtH32EGYxMhzN9oD/HFDRcvA+Sc1kafRNQRJjwHOWq4 shlJVkAQdZiV8pyqxlubc/dY6mSbHDo4PrEq/RatIAK34JVJClSddcxPVqoY9a3y VYxXUvj7sTKo72iHLFN6mdveEgFgCgLhUX4H404rLmXBkPNDCdxAhBYdrjYBCKac vTuME9y+kwcngOgnz7UyC+nGI/sld2ctQA3F1RDre1xmPDRiOfE4UHHWdW0GKh1e Mv0EhRj4H7pdNrYuGGrZ3BnHAAKgO336cxhGN5M+8l0TcP9gXN3PWdOmRGJHMJ/F 7U/+Mkk3YHuyVgA7mUxZ8PaoMT6miViwSRSFhh/pxiTP09AcHvOTP5uigDlRwBKq lKvNd761Smmc+37OnYxC/bV6DjRGGIXGWgzNcBbPnOZC4njjwwE/gZdijR7To1yy 1wEl4IQ71xl8R4Z4vOEa9UQVFwqidWEjtvr6juOPquZmVBOyeXQCALwieBzhYOpU pgX+xheYsC018/Mkyndl+D0U1Lsskc2h/gD4cPYfACiDxZOBFTa79hA76g+Jpgh2 Q21eK3qWux1M =Sw9F -END PGP SIGNATURE-
Bug#877876: python-zaqarclient: FTBFS: ModuleNotFoundError: No module named 'requests_mock'
Source: python-zaqarclient Version: 1.7.0-1 Severity: serious Justification: fails to build from source Hi, python-zaqarclient FTBFS in an up-to-date sid+experimental environment: [...] == ERROR: Failure: ModuleNotFoundError (No module named 'requests_mock') -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest raise self.exc_val.with_traceback(self.tb) File "/usr/lib/python3/dist-packages/nose/loader.py", line 418, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/usr/lib/python3.6/imp.py", line 235, in load_module return load_source(name, filename, file) File "/usr/lib/python3.6/imp.py", line 172, in load_source module = _load(spec) File "", line 684, in _load File "", line 665, in _load_unlocked File "", line 678, in exec_module File "", line 219, in _call_with_frames_removed File "/build/python-zaqarclient-1.7.0/tests/unit/cli/v1/test_queues.py", line 16, in from tests.unit.cli import fakes File "/build/python-zaqarclient-1.7.0/tests/unit/cli/fakes.py", line 18, in from osc_lib.tests import utils File "/usr/lib/python3/dist-packages/osc_lib/tests/utils.py", line 27, in from requests_mock.contrib import fixture ModuleNotFoundError: No module named 'requests_mock' -- Ran 190 tests in 0.201s FAILED (errors=1) debian/rules:13: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/build/python-zaqarclient-1.7.0' Andreas python-zaqarclient_1.7.0-1.log.gz Description: application/gzip
Bug#877875: python-requestsexceptions: insufficiently versioned B-D: python-pbr/python3-pbr
Source: python-requestsexceptions Version: 1.3.0-1 Severity: serious Justification: fails to build from source Hi, python-requestsexceptions FTBFS in a current sid+experimental environment with the sid versions of python-pbr/python3-pbr (1.10.0-1): fakeroot debian/rules clean pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions py3versions: no X-Python3-Version in control file, using supported versions dh clean --buildsystem=python_distutils --with python2,python3 dh_auto_clean -O--buildsystem=python_distutils pyversions: missing X(S)-Python-Version in control file, fall back to debian/pyversions pyversions: missing debian/pyversions file, fall back to supported versions python setup.py clean -a Download error on https://pypi.python.org/simple/pbr/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found! Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found! No local packages or working download links found for pbr>=2.0.0 Traceback (most recent call last): File "setup.py", line 29, in pbr=True) File "/usr/lib/python2.7/distutils/core.py", line 111, in setup _setup_distribution = dist = klass(attrs) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 325, in __init__ self.fetch_build_eggs(attrs['setup_requires']) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 446, in fetch_build_eggs replace_conflicting=True, File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 855, in resolve dist = best[req.key] = env.best_match(req, ws, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1127, in best_match return self.obtain(req, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1139, in obtain return installer(requirement) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 518, in fetch_build_egg return cmd.easy_install(req) File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 691, in easy_install raise DistutilsError(msg) distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('pbr>=2.0.0') dh_auto_clean: python setup.py clean -a returned exit code 1 debian/rules:7: recipe for target 'clean' failed make: *** [clean] Error 1 Andreas PS: network access is not available during build python-requestsexceptions_1.3.0-1.log.gz Description: application/gzip
Bug#877842: Pending fixes for bugs in the libxml-compile-soap-perl package
tag 877842 + pending thanks Some bugs in the libxml-compile-soap-perl package are closed in revision f7069513ccdbea788a13a574cca967dce98d13e6 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-compile-soap-perl.git/commit/?id=f706951 Commit message: Add build dependencies on libtest-deep-perl and libxml-compile-tester-perl. Thanks: Andreas Beckmann for the bug report. Closes: #877842
Bug#877874: RM: qlvnictools -- ROM; dead upstream, low popcorn, no maintainers
Package: ftp.debian.org Severity: normal Please, remove qlvnictools from the archive. Thank you, Ana
Bug#877870: lighttpd: "reload" action breaks further actions
Hi, (upstream) 1.4.46 will contain an updated unit file which includes a reload action, see https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/?h=0ae6bab4a97f12a0c93200df36ac1741696eeed5 for details. (Afaics the debian packages installs the upstream unit file). On 10/06/2017 03:53 PM, Andreas Hasenack wrote: > Package: lighttpd > Version: 1.4.45-1 > Severity: normal > > Dear Maintainer, > > After you issue a "service lighttpd reload" (or call /etc/init.d/lighttpd > directly with the same action), all further actions stop working. > > This happens because the "reload" action is not defined in the systemd > service file, so the code in /etc/init.d/lighttpd is used. That code in > turn restarts the service. When you later run status/stop/start/restart, > these are done via systemd and it thinks the service is dead because the > PID changed. > > For example, starting with a running lighttpd: > root@sid-lighttpd-reload-1721635:~# ps fxaw > PID TTY STAT TIME COMMAND > (...) > 17184 ?Ss 0:00 /usr/sbin/lighttpd -D -f > /etc/lighttpd/lighttpd.conf > root@sid-lighttpd-reload-1721635:~# service lighttpd status > ● lighttpd.service - Lighttpd Daemon >Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor > preset: enabled) >Active: active (running) since Fri 2017-10-06 13:48:53 UTC; 4s ago > (...) > > Let's reload: > root@sid-lighttpd-reload-1721635:~# service lighttpd reload > [ ok ] Reloading web server configuration: lighttpd. > > Status now is dead: > root@sid-lighttpd-reload-1721635:~# service lighttpd status > ● lighttpd.service - Lighttpd Daemon >Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor > preset: enabled) >Active: inactive (dead) since Fri 2017-10-06 13:49:08 UTC; 2s ago > Process: 17184 ExecStart=/usr/sbin/lighttpd -D -f > /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) > Process: 17177 ExecStartPre=/usr/sbin/lighttpd -tt -f > /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) > Main PID: 17184 (code=exited, status=0/SUCCESS) > > But it's still running, albeit a new copy: > root@sid-lighttpd-reload-1721635:~# ps fxaw > PID TTY STAT TIME COMMAND > (...) > 17231 ?S 0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf > > "start" will fail now, for example: > root@sid-lighttpd-reload-1721635:~# service lighttpd status > ● lighttpd.service - Lighttpd Daemon >Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor > preset: enabled) >Active: failed (Result: exit-code) since Fri 2017-10-06 13:51:25 UTC; > 836ms ago > Process: 17391 ExecStart=/usr/sbin/lighttpd -D -f > /etc/lighttpd/lighttpd.conf (code=exited, status=255) > Process: 17384 ExecStartPre=/usr/sbin/lighttpd -tt -f > /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) > Main PID: 17391 (code=exited, status=255) > > Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service: > Unit entered failed state. > Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service: > Failed with result 'exit-code'. > > journalctl shows the reason: > Oct 06 13:51:24 sid-lighttpd-reload-1721635 lighttpd[17377]: 2017-10-06 > 13:51:24: (network.c.464) can't bind to port: 80 Address already in use > > Managing this service via systemd or sysv is now effectively broken. >
Bug#877873: RM: libpcap-dev [all] -- RoQA; obsolete arch:all package
Package: ftp.debian.org Severity: normal Hi, libpcap-dev is now arch:any libpcap-dev | 1.8.1-4 | unstable | all libpcap-dev | 1.8.1-5 | unstable | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Andreas
Bug#877841: Pending fixes for bugs in the libxml-compile-wsdl11-perl package
tag 877841 + pending thanks Some bugs in the libxml-compile-wsdl11-perl package are closed in revision e18c54cebaef92fba9a7405ffdad1ca88f4629b2 in branch 'master' by gregor herrmann The full diff can be seen at https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-compile-wsdl11-perl.git/commit/?id=e18c54c Commit message: Add build dependency on libxml-compile-tester-perl. Thanks: Andreas Beckmann for the bug report. Closes: #877841
Bug#877872: RM: r-cran-backports [all] -- RoQA; obsolete arch:all package
Package: ftp.debian.org Severity: normal * package r-cran-backports in version 1.0.5-1 is no longer built from source - suggested command: dak rm -m "[auto-cruft] no longer built from source" -s unstable -a all -p -R -b r-cran-backports - broken Depends: r-cran-checkmate: r-cran-checkmate r-cran-rprojroot: r-cran-rprojroot - broken Build-Depends: r-cran-checkmate: r-cran-backports r-cran-rprojroot: r-cran-backports r-cran-backports is now arch:any: r-cran-backports | 1.0.5-1 | unstable | all r-cran-backports | 1.1.1-1 | unstable | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Andreas
Bug#877871: RFP: pyside2 -- Python bindings for Qt5
Package: wnpp Severity: wishlist * Package name: pyside2 Version : 2.0.0.dev0 Upstream Author : PySide2 Team * URL : https://wiki.qt.io/PySide * License : LGPL3, GPL3+ Programming Lang: C++, Python Description : Python bindings for Qt5 (information mainly from https://code.qt.io/cgit/pyside/pyside-setup.git/tree/setup.py) Long description can probably copied from pyside. PySide2 is the successor of PySide and is a dependency for at least FreeCAD and python-ghost. PySide will be removed from Debian soon, so PySide2 must be packaged. Dominique Belhachemi explains how to get PySide2 from a Ubuntu PPA on Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784512#78 Maybe also helpful: https://wiki.qt.io/PySide2_GettingStarted -- "Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder
Bug#870860: openjfx: CVE-2017-10086 CVE-2017-10114
On Fri, Oct 06, 2017 at 04:27:02PM +0200, Emmanuel Bourg wrote: > Hi, > > Quick update on openjfx: the package is back on track, as of version > 8u141-b14-3 I eventually managed to get it to build on both amd64 and > i386 in unstable for the first time since January. If the tests go well > I'll prepare the security update next week. Thanks. Cheers, Moritz