Bug#814426: sympa: New upstream version available (6.2.12)
Quoting Jérôme Lebleu (2016-06-26 16:02:22) > Hi Jonas, > > On Sat, 25 Jun 2016 13:45:22 +0200 Jonas Smedegaard wrote: > > Quoting Jérôme Lebleu (2016-06-25 11:22:11) > >> I've just never contributed yet and I'm not a Debian developer too > >> - but after reading https://www.debian.org/devel/join/ it seems > >> that it's not required and even a good gateway, or I'm wrong? [...] > > At a minimum you can propose patches by email. [...] > > Here are some pointers to get you started: > > https://alioth.debian.org/projects/pkg-sympa/ > > https://wiki.debian.org/Alioth/FAQ > > https://wiki.debian.org/Alioth/SSH#Logging_in_for_the_first_time > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sympa-devel > > https://tracker.debian.org/pkg/sympa > > http://anonscm.debian.org/gitweb/?p=collab-maint/sympa.git > > > > (hmm, which reveals: We really could use a nice wiki intro page for our > > team at the Debian wiki...) [...] > Thank you for all of this information, links and others! :-) > > I've subscribed to the pkg-sympa-devel mailing list and created an > account at Alioth (I think I understood what you mean by "don't try > make sens of Alioth web interface"...!). Great! > I'll wait until Emmanuel has time to push his 6.2 branch in order to > see if I can help - and how, and proposing you a first patch by email > before requesting membership to your Alioth group. > > Anyway, I'm already delighted with our few exchanges and impatient to > start contributing! Well, one thing you need not wait for - on the contrary, in fact: (Create a wiki account, and) add a page for our team at the Debian wiki, and then link it to https://wiki.debian.org/Teams (where you can get inspiration from the numerous other teams on what is sensible to write on such page. :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#826089: [check-all-the-things] 02/02: Only act on arguments once when parsing text for the -c/-f options
On Sun, 2016-06-26 at 16:40 +0200, Jakub Wilk wrote: > After this commit, the command > > check-all-the-things -f=-network > > no longer disables network access. :-( There are more bugs introduced by it too, working on fixing that now. > I don't think there's a sane way to fix #826089 without bringing back > distinction between topical groups and flags indicating potentially > unwanted behavior. (I don't like the name "flags"; I'd call them > "inhibitors" or something.) Bug #826089 happens with the code that had both -g and -f so I don't think bringing back groups will help at all. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#828636: libembperl-perl: please make the build reproducible
Source: libembperl-perl Version: 2.5.0-6 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that libembperl-perl could not be built reproducibly. In one build the manpage Embperl::Syntax::POD.3pm is incorrectly sorted to the German manpages (Embperl::FeaturesD too), because their names end with D. As the package provides no German manpages anyway, I think the part in debian/rules, which moves the manpages can be safely removed. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/debian/rules b/debian/rules index f643b0b..ab91682 100755 --- a/debian/rules +++ b/debian/rules @@ -27,14 +27,6 @@ override_dh_auto_install: $(POD2TEXT) # install by default install -m 755 *cgi.pl debian/libembperl-perl/usr/lib/cgi-bin/ - # move German manpages to usr/share/man/de/man{1,2,3} - @set -e;\ - for f in $(TMP)/usr/share/man/man3/*[a-z]D.3pm; do \ - f_de=`echo $$f | sed 's,man\(.\)/\([^/]*\)D\.\([^/]*\)$$,de/man\1/\2.\3,'` ;\ - echo "mv $$f $$f_de" ;\ - mv $$f $$f_de ;\ - done - # ship Apache config in mods-available sed -e 's,@ARCHLIB@,$(ARCHLIB),g' debian/zembperl.load.in > debian/zembperl.load install -m 644 debian/zembperl.conf debian/zembperl.load \
Bug#826089: [check-all-the-things] 02/02: Only act on arguments once when parsing text for the -c/-f options
* Paul Wise , 2016-06-26, 09:45: commit 8f70b2e913bf82c7bd2eea5a006e95dbef843063 Author: Paul Wise Date: Sun Jun 26 11:41:56 2016 +0200 Only act on arguments once when parsing text for the -c/-f options After this commit, the command check-all-the-things -f=-network no longer disables network access. :-( I don't think there's a sane way to fix #826089 without bringing back distinction between topical groups and flags indicating potentially unwanted behavior. (I don't like the name "flags"; I'd call them "inhibitors" or something.) -- Jakub Wilk
Bug#828398: libmongoc: FTBFS with openssl 1.1.0
Thanks; we're tracking this in the upstream bug tracker here: https://jira.mongodb.org/browse/CDRIVER-1066 On Sun, Jun 26, 2016 at 6:22 AM, Kurt Roeckx wrote: > Source: libmongoc > Version: 1.3.5-1 > Severity: important > Control: block 827061 by -1 > > Hi, > > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > OpenSSL this package fail to build. A log of that build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/libmongoc_1.3.5-1_amd64-20160529-1442 > > On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of > the > reasons why it might fail. There are also updated man pages at > https://www.openssl.org/docs/manmaster/ that should contain useful > information. > > There is a libssl-dev package available in experimental that contains a recent > snapshot, I suggest you try building against that to see if everything works. > > If you have problems making things work, feel free to contact us. > > > Kurt
Bug#811970: blackbox: FTBFS with GCC 6: symbol changes
Hi, On Tue, 19 Jan 2016 20:09:51 -0800 Martin Michlmayr wrote: > Package: blackbox > Version: 0.70.1-30 > Severity: important > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-6 gcc-6-symbols > > This package fails to build with GCC 6. GCC 6 has not been released > yet, but it's expected that GCC 6 will become the default compiler for > stretch. > > Note that only the first error is reported; there might be more. You > can find a snapshot of GCC 6 in experimental. To build with GCC 6, > you can set CC=gcc-6 CXX=g++-6 explicitly. I am trying to fix this bug. regards, -- signature.asc Description: This is a digitally signed message part
Bug#828625: nethack-console: wizard mode permanently identify does not works on armhf port
Control: forwarded -1 devt...@nethack.org Control: tags -1 pending Hi, On Sun, 2016-06-26 at 20:02 +0800, Mo Jun wrote: > Package: nethack-console > Version: 3.6.0-3 > Severity: normal > Tags: patch > > Dear Maintainer, > > 1. This bug is only found on armhf port; it is not found on amd64 port. > It can be reproduced on a chroot Debian system on a ARMv7 smart phone > and on a full Debian system in a QEMU virtual machine. [...] > When ^I is pressed in the Debug Identify menu, the identifier will be > returned by display_pickinv(). And wiz_identify() will check whether the > return value of display_pickinv() equals -1(src/cmd.c:595): > if (display_inventory((char *) 0, TRUE) == -1) > then determine to fully identify all items or do nothing. > > However the type char is unsigned by default on arm port. "any.a_char = -1;" > will set any.a_char to 255 actually on arm port(this can be verified > by using gdb), so > that above if statement will never success, and the permanent wizard > identify > will never be performed. Your reasoning seems perfectly sound to me, and I can reproduce the bug on one of Debian's armhf porterboxes. I've sent an email to the Nethack devteam about this bug, and I'll upload your patch in a few moments. Thanks a lot! James signature.asc Description: This is a digitally signed message part
Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0
block 828618 by 828462 thanks On Sun, Jun 26, 2016 at 03:15:30PM +0100, Thomas Leonard wrote: > > I don't mind. I guess blocks might be better, to remind me to test it > when the ocaml-ssl bug is fixed. So I've set that.
Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0
On 26 June 2016 at 13:15, Kurt Roeckx wrote: > On Sun, Jun 26, 2016 at 12:20:33PM +0100, Thomas Leonard wrote: >> On 26 June 2016 at 11:24, Kurt Roeckx wrote: >> > Hi, >> > >> > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using >> > OpenSSL this package fail to build. A log of that build can be found at: >> > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zeroinstall-injector_2.10-2_amd64-20160530-2117 >> > >> > On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various >> > of the >> > reasons why it might fail. There are also updated man pages at >> > https://www.openssl.org/docs/manmaster/ that should contain useful >> > information. >> > >> > There is a libssl-dev package available in experimental that contains a >> > recent >> > snapshot, I suggest you try building against that to see if everything >> > works. >> > >> > If you have problems making things work, feel free to contact us. >> >> The problem appears to be in ocaml-ssl. See: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828462 > > So should it just be merged, or do you want to have 1 block the > other? I don't mind. I guess blocks might be better, to remind me to test it when the ocaml-ssl bug is fixed. Thanks, -- talex5 (GitHub/Twitter)http://roscidus.com/blog/ GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA
Bug#828088: licensecheck invokes find with -follow
On Friday 24 June 2016 22:51:56 Sandro Mani wrote: > I think [-follow] should be removed, for > three reasons. Reason 1: self loops like the one in giac make find, and > therefore licensecheck, fail. Reason 2: symlinks can point anywhere. Do > you really want to let licensecheck run over arbitrary parts of the > filesystem? Reason 3: every file in a package *should* be reachable > without traversing symlinks at all. (If fedora-review doesn't have a check > for that, it probably should.) I agree with point 2 above. A symlinks either points: - inside the scanned package and the file will be found by find with another path (furthermote, using -follow may lead to duplicate results) - a symlink points in another package and it license should be covered by the license description of the other package. The commit [1] that added -follow with the scan directory feature does not mention any specific reason to use -follow option. All in all, I think -follow option should be removed. Thoughts ? All the best [1] https://anonscm.debian.org/cgit/collab-maint/devscripts.git/commit/?id=ffd90771b2a4ebd22bc3e27d2415112fbc506571 -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
Bug#828635: libnet-tclink-perl: please make the build reproducible
Source: libnet-tclink-perl Version: 2.4.9.1+dfsg-1.5 Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: uname X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that libnet-tclink-perl could not be built reproducibly. It embeds the current kernel/machine name into a library. The attached patch replaces this with a static value instead. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch new file mode 100644 index 000..6ab0a11 --- /dev/null +++ b/debian/patches/reproducible_build.patch @@ -0,0 +1,14 @@ +Author: Reiner Herrmann +Description: Don't include kernel/machine name to get reproducible build + +--- a/Makefile.PL b/Makefile.PL +@@ -26,7 +26,7 @@ + # See lib/ExtUtils/MakeMaker.pm for details of how to influence + # the contents of the Makefile that is written. + +-my $platform = `uname -sm`; ++my $platform = "Debian"; + chomp($platform); + $platform =~ s/ /-/g; + diff --git a/debian/patches/series b/debian/patches/series index 835d0a3..cd72032 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ add-shebang.patch disable-network-test.patch no-SSLv3.patch +reproducible_build.patch
Bug#814426: sympa: New upstream version available (6.2.12)
Hi Jonas, On Sat, 25 Jun 2016 13:45:22 +0200 Jonas Smedegaard wrote: > Quoting Jérôme Lebleu (2016-06-25 11:22:11) > [...] >> I've just never contributed yet and I'm not a Debian developer too - >> but after reading https://www.debian.org/devel/join/ it seems that >> it's not required and even a good gateway, or I'm wrong? > > Correct: You need no formal membership of Debian to contribute. > > At a minimum you can propose patches by email. Slightly easier (for us > to handle, but slightly more cumbersome for you) is if those emails are > bugreports that you file. Most convenient and fun - both for us and and > you - is that you a) subscribe to our mailinglist and b) join our team > by creating an account at Alioth and request membership to our Alioth > group. Basically that grants you write access to our git. > > [...] > >> Anyway, if you have some time to guide me or give me advices on how to >> contribute and help you... I'll be most grateful!! > > Here are some pointers to get you started: > https://alioth.debian.org/projects/pkg-sympa/ > https://wiki.debian.org/Alioth/FAQ > https://wiki.debian.org/Alioth/SSH#Logging_in_for_the_first_time > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sympa-devel > https://tracker.debian.org/pkg/sympa > http://anonscm.debian.org/gitweb/?p=collab-maint/sympa.git > > (hmm, which reveals: We really could use a nice wiki intro page for our > team at the Debian wiki...) > > NB! Don't try make sense of Alioth web interface - use it *only* to > become member of our team, and then avoid it as much as possible, > instead using the alternative debian subdomains wiki, anonscm, lists! Thank you for all of this information, links and others! :-) I've subscribed to the pkg-sympa-devel mailing list and created an account at Alioth (I think I understood what you mean by "don't try make sens of Alioth web interface"...!). I'll wait until Emmanuel has time to push his 6.2 branch in order to see if I can help - and how, and proposing you a first patch by email before requesting membership to your Alioth group. Anyway, I'm already delighted with our few exchanges and impatient to start contributing! Jérôme signature.asc Description: OpenPGP digital signature
Bug#828453: nginx: FTBFS with openssl 1.1.0
Hi, probably related: https://trac.nginx.org/nginx/ticket/860 Cheers Elrond
Bug#682816: xserver-xorg-core: Xorg freezes with i915 intel_crtc_wait_for_pending_flips problem
Sorry, I haven't been using debian for some time, so cannot comment anymore. Regards, Joseph On 22 June 2016 at 21:54, Francesco Poli wrote: > On Mon, 14 Jul 2014 22:28:05 +0200 Francesco Poli wrote: > > > I had found out that the issue vanishes when using SNA acceleration. > [...] > > and I am keeping DPMS disabled. > [...] > > Is there any progress on this issue? > > These two issues (#714531 [1] and #682816 [2]) seem to have disappeared > (at least) since > xserver-xorg-video-intel/2:2.99.917+git20160325-1 > linux-image-4.5.0-2-amd64/4.5.3-2 > > [1] https://bugs.debian.org/714531 > [2] https://bugs.debian.org/682816 > > I haven't experienced them for quite some time, after re-enabling DPMS > and while using the default acceleration (which is now SNA, as far as I > can tell). > > Olivier, Joseph, Wolodja, do you still experience any of the two bugs? > Please let me know, thanks for your time. > > If nobody objects in the next 30 days, I will reassign bug #714531 > to package xserver-xorg-video-intel and close both bug > reports (#714531 and #682816) as fixed in > xserver-xorg-video-intel/2:2.99.917+git20160325-1 > > Bye. > > -- > http://www.inventati.org/frx/ > There's not a second to spare! To the laboratory! > . Francesco Poli . > GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE >
Bug#828629: nvidia-driver 355.11-2 (experimental, amd64) not installable
Control: tags -1 moreinfo On Sun, 2016-06-26 at 14:34 +0200, Roman Horn�k wrote: > Package: nvidia-driver > Version: 352.79-8 > Severity: important > > Hi, > > this package is not installable due to missing nvidia-settings 355.11-2 (only > 346.59-1 is available). > > Roman > Hi, What's the actual error you get? The drivers and settings packages are largely independent. The drivers only recommend nvidia-settings, they do not depend on it. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#828634: python-oauth2client: FTBFS: error: [Errno 110] Connection timed out
Source: python-oauth2client Version: 2.0.1-3 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, python-oauth2client fails to build from source in unstable/amd64: [..] test_get_environment_variable_file_error (tests.test_client.GoogleCredentialsTests) ... ok test_get_well_known_file_on_windows (tests.test_client.GoogleCredentialsTests) ... ok test_get_well_known_file_with_custom_config_dir (tests.test_client.GoogleCredentialsTests) ... ok test_parse_expiry (tests.test_client.GoogleCredentialsTests) ... ok test_raise_exception_for_missing_fields (tests.test_client.GoogleCredentialsTests) ... ok test_raise_exception_for_reading_json (tests.test_client.GoogleCredentialsTests) ... ok test_save_to_well_known_file_authorized_user (tests.test_client.GoogleCredentialsTests) ... ok test_save_to_well_known_file_service_account (tests.test_client.GoogleCredentialsTests) ... ok test_save_well_known_file_with_non_existent_config_dir (tests.test_client.GoogleCredentialsTests) ... ok test_to_from_json_authorized_user (tests.test_client.GoogleCredentialsTests) ... ok test_to_from_json_service_account (tests.test_client.GoogleCredentialsTests) ... ok test_get_set_delete (tests.test_client.MemoryCacheTests) ... ok test_construct_authorize_url (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_dictlike (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_fails_if_no_code (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_failure (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_failure_with_json_error (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_id_token (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_id_token_fail (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_no_expires_in (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_success (tests.test_client.OAuth2WebServerFlowTest) ... ok test_exchange_using_authorization_header (tests.test_client.OAuth2WebServerFlowTest) ... ok Passing kwargs to override defaults. ... ok test_scope_is_required (tests.test_client.OAuth2WebServerFlowTest) ... ok test_urlencoded_exchange_failure (tests.test_client.OAuth2WebServerFlowTest) ... ok test_urlencoded_exchange_no_expires_in (tests.test_client.OAuth2WebServerFlowTest) ... ok test_urlencoded_exchange_success (tests.test_client.OAuth2WebServerFlowTest) ... ok test_urlencoded_expires_param (tests.test_client.OAuth2WebServerFlowTest) ... ok test_assertion_body (tests.test_client.TestAssertionCredentials) ... ok test_assertion_refresh (tests.test_client.TestAssertionCredentials) ... ok test_sign_blob_abstract (tests.test_client.TestAssertionCredentials) ... ok test_token_revoke_failure (tests.test_client.TestAssertionCredentials) ... ok test_token_revoke_success (tests.test_client.TestAssertionCredentials) ... ok test_existing (tests.test_client.Test__save_private_file) ... ok test_new (tests.test_client.Test__save_private_file) ... ok test_update_query_params_existing_params (tests.test_client.UpdateQueryParamsTest) ... ok test_update_query_params_no_params (tests.test_client.UpdateQueryParamsTest) ... ok test_cache_hit (tests.test_clientsecrets.CachedClientsecretsTests) ... ok test_cache_miss (tests.test_clientsecrets.CachedClientsecretsTests) ... ok test_validation (tests.test_clientsecrets.CachedClientsecretsTests) ... ok test_without_cache (tests.test_clientsecrets.CachedClientsecretsTests) ... ok test_load_by_filename_missing_file (tests.test_clientsecrets.OAuth2CredentialsTests) ... ok test_validate_error (tests.test_clientsecrets.OAuth2CredentialsTests) ... ok test_bad_json (tests.test_clientsecrets.Test__loadfile) ... ok test_non_existent (tests.test_clientsecrets.Test__loadfile) ... ok test_success (tests.test_clientsecrets.Test__loadfile) ... ok test_invalid_client_type (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_missing_required_type_installed (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_missing_required_type_web (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_string_not_configured_type_installed (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_string_not_configured_type_web (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_success_type_installed (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_success_type_web (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_with_non_dictionary (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_with_none (tests.test_clientsecrets.Test__validate_clientsecrets) ... ok test_with_other_than_one_key (tests.test_clientsecrets.Test__vali
Bug#789381: libpoe-api-peek-perl: FTBFS with perl 5.22: test failures
Hi, Niko Tyni wrote (21 May 2016 16:03:54 GMT) : > There's been no reaction to this upstream in more than a year. > We discussed this package at the Debian Perl Team Sprint in Zürich, > and we think it should be removed from Debian. FWIW, I concur. > However, it has a reverse > dependency chain to webgui through libpoe-component-ikc-perl. Also, libpoe-component-server-http-perl Build-Depends on libpoe-api-peek-perl, that itself has very low popcon (vote: 2) and no {build,runtime} reverse dependencies, so IMO this reveres-build-dep should not block removal. Cheers, -- intrigeri
Bug#789381: libpoe-api-peek-perl: FTBFS with perl 5.22: test failures
Hi, Prof. Ernesto Hernández-Novich wrote (23 May 2016 11:49:55 GMT) : > On Sat, 21 May 2016 19:03:54 +0300 Niko Tyni wrote: > webgui has never been part of any stable release. WebGUI's upstream has > been very slow for the last year or so, with only a couple of releases. > The latest release, about a month and a half ago, still lists > POE::Component::IKC as a dependency and it's used for a core workflow > component -- it requires 0.2001 > I've written upstream about their thoughts on the issue. Did you get any feedback from them yet? > I've no particular opinion on what to do with libpoe-api-peek-perl -- > I certainly don't know how to fix it. If removal is the sane choice, go > ahead and remove both. OK, thank you! Cheers, -- intrigeri
Bug#828633: mount in testing/unstable should conflict with old bash-completion
Package: mount Version: 2.28-5 Severity: normal Below is the results of "apt-get dist-upgrade" to upgrade from Jessie to testing. If I manually upgrade bash-completion first then mount can be upgraded without problems. Preparing to unpack .../mount_2.28-5_amd64.deb ... Unpacking mount (2.28-5) over (2.27.1-3.1) ... dpkg: error processing archive /var/cache/apt/archives/mount_2.28-5_amd64.deb (--unpack): trying to overwrite '/usr/share/bash-completion/completions/mount', which is also in package bash-completion 1:2.1-4.3 Errors were encountered while processing: /var/cache/apt/archives/mount_2.28-5_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mount depends on: ii libblkid1 2.27.1-3.1 ii libc6 2.22-11 ii libmount1 2.28-5 ii libselinux12.3-2 ii libsmartcols1 2.28-5 ii libudev1 230-2 mount recommends no packages. Versions of packages mount suggests: ii nfs-common 1:1.2.8-9 -- no debconf information
Bug#828632: tidy-html5: FTBFS on !linux archs
Source: tidy-html5 Version: 1:5.2.0-1 Severity: important Control: forwarded -1 https://github.com/htacg/tidy-html5/pull/423 Hi, tidy-html5 fails to compile on kFreeBSD [1][2] and Hurd [3]. The reason of the failure is the lack of the 02FTBS_kfreebsd-gnu.patch from the old src:tidy -- OTOH, I proposed upstream a simplier patch [4] for supporting all the glibc-based systems at once. Feel free to pick whichever version you prefer, but please do integrate one solution so even non-Linux architectures can use the new source. [1] https://buildd.debian.org/status/fetch.php?pkg=tidy-html5&arch=kfreebsd-amd64&ver=1%3A5.2.0-1&stamp=1466341667 [2] https://buildd.debian.org/status/fetch.php?pkg=tidy-html5&arch=kfreebsd-i386&ver=1%3A5.2.0-1&stamp=1466336333 [3] https://buildd.debian.org/status/fetch.php?pkg=tidy-html5&arch=hurd-i386&ver=1%3A5.2.0-1&stamp=1466342177 [4] https://github.com/htacg/tidy-html5/pull/423 Thanks, -- Pino
Bug#791636: higan: Load and save state do not work without having focus
Hi, thanks for the bug report. If someone provides a patch for this, I could apply it. Otherwise you could try reporting this upstream. Best, Tobias On Mon, 06 Jul 2015 22:22:18 -0300 Christian Weinz wrote: > Package: higan > Version: 094-5 > Severity: normal > > Dear Maintainer, > > when assigning save and load state to buttons on a gamepad they don't work > when > higan doesn't have focus even when the option to allow input when focus is > lost > is enabled. > > I'd expect gamepad buttons to work for every assigned action even when focus > is > lost. > > > > -- System Information: > Debian Release: stretch/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=pt_BR.utf8, LC_CTYPE=pt_BR.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages higan depends on: > ii libao41.1.0-3 > ii libasound21.0.29-1 > ii libatk1.0-0 2.16.0-2 > ii libc6 2.19-18 > ii libcairo2 1.14.2-2 > ii libfontconfig12.11.0-6.3 > ii libfreetype6 2.5.2-4 > ii libgcc1 1:5.1.1-12 > ii libgdk-pixbuf2.0-02.31.4-2 > ii libgl1-mesa-glx [libgl1] 10.5.8-1 > ii libglib2.0-0 2.44.1-1.1 > ii libgtk2.0-0 2.24.28-1 > ii libopenal11:1.16.0-3 > ii libpango-1.0-01.36.8-3 > ii libpangocairo-1.0-0 1.36.8-3 > ii libpangoft2-1.0-0 1.36.8-3 > ii libpulse0 6.0-2 > ii libsdl1.2debian 1.2.15-11 > ii libstdc++65.1.1-12 > ii libudev1 221-1 > ii libx11-6 2:1.6.3-1 > ii libxext6 2:1.3.3-1 > ii libxv12:1.0.10-1+b1 > > higan recommends no packages. > > higan suggests no packages. > > -- no debconf information > >
Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim
Hello, On Sun, Jun 26, 2016 at 12:02:43PM +0200, Axel Beckert wrote: > The command as on the wiki didn't work as it misses the trailing ";" > for the command and if that's added, only lists tons of "TODO". The 'TODO' meant that I hadn't finished figuring out the command :P Some `packages.el' files specify more than one package to be downloaded from MELPA. For example, in layers/+lang/elm/package.el: (setq elm-packages '( company elm-mode flycheck flycheck-elm popwin smartparens )) I'd started writing lots of regexps to get the list of packages out but I think it might be better just to invoke Emacs to, you know, parse the lisp.. > According to "wc -l" this are 111 packages. From the logs of my first > spacemacs run, it only seems to have downloaded 69 of them. And I > don't have all available *-el and elpa-* packages installed on that > system. So I also checked .emacs.d/elpa where it seems to store the > downloaded packages: I'm not sure whether this is a viable alternative to my approach or not -- I don't think Spacemacs downloads all the packages on a first run. I think that some layers are considered 'optional'. If there was some way to know that we had activated every single layer, and we did it in a clean sid chroot, it would give the correct list. We could make a team decision to package spacemacs once all the compulsory dependencies are packaged, or we could wait until we have the packages that every single layer requires. -- Sean Whitton signature.asc Description: PGP signature
Bug#800816: plinth: please make the build reproducible
[Sunil Mohan Adapa] > Last I tried, apart from the time issue, I believe I also got an issue > with the way some images were generated into the resulting PDF. The > generated image code would simply change from one run to another. IIRC, > I worked around time issue using 'faketime': > https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal . We > could use that in our doc/Makefile if the other issues are resolved. Right. I tested using faketime, and can confirm that the PDF changes every time. The creationDate according to pdfinfo is also different, apparently it take between 3 and 4 seconds to generate the PDF on my machine. But the PDF checksum changes also when the CreationDate second is same, so there is something else changing too. -- Happy hacking Petter Reinholdtsen
Bug#774970: dnsmasq should depend on network-online.target when binding to device
Package: dnsmasq Version: 2.76-1 Followup-For: Bug #774970 Dear Maintainer, masq start before the wifi/lan bridge is up, so the bind to device fails: root@apu:~# journalctl |grep br0 giu 26 14:25:10 apu dnsmasq[282]: dnsmasq: unknown interface br0 giu 26 14:25:10 apu dnsmasq[282]: unknown interface br0 giu 26 14:25:11 apu systemd-udevd[464]: Could not generate persistent MAC address for br0: No such file or directory giu 26 14:25:11 apu kernel: br0: port 1(eth1) entered blocking state giu 26 14:25:11 apu kernel: br0: port 1(eth1) entered disabled state giu 26 14:25:11 apu kernel: br0: port 2(eth2) entered blocking state giu 26 14:25:11 apu kernel: br0: port 2(eth2) entered disabled state giu 26 14:25:11 apu kernel: IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready giu 26 14:25:15 apu kernel: br0: port 1(eth1) entered blocking state giu 26 14:25:15 apu kernel: br0: port 1(eth1) entered forwarding state giu 26 14:25:15 apu kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready root@apu:~# systemctl status -l networking.service ● networking.service - Raise network interfaces Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf Active: failed (Result: exit-code) since dom 2016-06-26 14:25:47 CEST; 16min ago Docs: man:interfaces(5) Process: 182 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE) Process: 177 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (code=exited, Main PID: 182 (code=exited, status=1/FAILURE) giu 26 14:25:15 apu ifup[182]: nl80211 driver initialization failed. giu 26 14:25:15 apu ifup[182]: wlan1: interface state UNINITIALIZED->DISABLED giu 26 14:25:15 apu ifup[182]: wlan1: AP-DISABLED giu 26 14:25:15 apu ifup[182]: hostapd_free_hapd_data: Interface wlan1 wasn't started giu 26 14:25:15 apu ifup[182]: Failed to bring up wlan1. giu 26 14:25:15 apu systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE giu 26 14:25:47 apu pppd[570]: Timeout waiting for PADO packets giu 26 14:25:47 apu systemd[1]: Failed to start Raise network interfaces. giu 26 14:25:47 apu systemd[1]: networking.service: Unit entered failed state. giu 26 14:25:47 apu systemd[1]: networking.service: Failed with result 'exit-code'. root@apu:~# systemctl status -l dnsmasq.service ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/dnsmasq.service.d └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf Active: failed (Result: exit-code) since dom 2016-06-26 14:25:10 CEST; 16min ago Process: 282 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=2) Process: 266 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) giu 26 14:25:10 apu systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... giu 26 14:25:10 apu dnsmasq[266]: dnsmasq: syntax check OK. giu 26 14:25:10 apu dnsmasq[282]: dnsmasq: unknown interface br0 giu 26 14:25:10 apu systemd[1]: dnsmasq.service: Control process exited, code=exited status=2 giu 26 14:25:10 apu systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server. giu 26 14:25:10 apu systemd[1]: dnsmasq.service: Unit entered failed state. giu 26 14:25:10 apu systemd[1]: dnsmasq.service: Failed with result 'exit-code'. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-apu+ (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dnsmasq depends on: ii dnsmasq-base 2.76-1 ii init-system-helpers 1.34 ii netbase 5.3 dnsmasq recommends no packages. Versions of packages dnsmasq suggests: pn resolvconf -- Configuration Files: /etc/dnsmasq.conf changed [not included] -- no debconf information
Bug#828631: RM: nepomuk-widgets -- ROM; dead upstream, no more used
Package: ftp.debian.org Severity: normal Hi, please remove nepomuk-widgets, since it's part of the unmaintained Nepomuk stack in KDE/Plasma 4. Thanks, -- Pino
Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've prepared an update for libbusiness-creditcard-perl in jessie{,-updates} which fixes #814479 for stable users. The issue at hand is that the credit card ranges of several providers need to be updated. In practice there are several options to do this update in stable: - - What I've prepared (attached as a debdiff) for now is to backport the functional and some documentation changes from 0.34 and 0.35 to 0.33 in 3 logically separate quilt patches, in order to make reviewing easy. In practice this leaves out only some minor changes in metadata and unrelated documentation changes from 0.35. - - Ivan (upstream and Debian contributor) originally asked to take the 0.35 release and upload it to stable (presumably as 0.35-0+deb8u1). This had the advantage of shipping a fully tested release but is probably not the release team's typically preferred way. -- Complete diff: https://metacpan.org/diff/file?target=IVAN%2FBusiness-CreditCard-0.35%2F&source=IVAN%2FBusiness-CreditCard-0.33%2F - - In regard to my patch series, Ivan pointed out in #814479 that we might as well change $VERSION in the code to 0.35 since that's what it functionally is. I'm fine with all of these versions (and I'm happy to prepare debdiffs for the second and the third in case you prefer them); please advice on your preferred way of proceeding. Cheers, gregor -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJXb9QuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGDa4P+wS+Mbzuwqi0W2uxAe5sVLid 2J7KARfvBynDwPQQBCl8GXW5mtpmpHHwSkdSku3g0M2KJTHyyWSNppvjTOWxKlgF 3McUUGkxOVik1ZqV3OMd9kFPJ9/ezp9L8WazkvCT5Z6F9gFR+TYSNLg6up108hr9 /deT+r7l0nxbkKgS7UV4ql//+VRCWxzTp5zf7V85AvEXfwukXp8oIQ0GORhIcVvW yS/ZmAZYjXUNb4mEzxHqJ8XIlzcHSIYIYB/oC+Km25qLEmXTHG/hdv2AcRQ91+1E nSczegDtku8RkzAgZ1veU7N5yCTzwgPHrtdCzipYE/xjb95dl/VLOHg+qFES4Hvl EMtNUYKZxzsdBFZN+AqNL+z1OM32BDeVEscp3ukZyJwmVG2034ikkcuTiiq5CVqq fE5cX+5NQMW1eVfuxjE7C0CTusJJmav/Q9PxdVRSNWUXlpybYgd8oYrpKtt4WlcW kME61QKByiv1olUOs7ymyRxgu9xHZSo4kyMVQs12bZs7CWr3uylsAfXBWm9J5b72 i/BbtZiItIEpVCYEeeX7GH2L4l45rNNJOQ3sUNY/6ko3gz0LbuvZXvOSCsl7oCEW DdyzHEMvC3IrgYvLRpXXtsphQSpkpMFi4axAP9fqSfj5Q5dcRSn5LtCr1VSxcI5l MzrXdUIr5kIMUmUPtwvq =5HrC -END PGP SIGNATURE- diff -Nru libbusiness-creditcard-perl-0.33/debian/changelog libbusiness-creditcard-perl-0.33/debian/changelog --- libbusiness-creditcard-perl-0.33/debian/changelog 2016-06-26 14:52:12.0 +0200 +++ libbusiness-creditcard-perl-0.33/debian/changelog 2016-06-26 14:51:25.0 +0200 @@ -1,3 +1,19 @@ +libbusiness-creditcard-perl (0.33-1+deb8u1) UNRELEASED; urgency=medium + + * Backport changes from upstream releases 0.34 and 0.35 to adjust to +changes in credit card ranges and processing of various companies. + +Add the following patches: +- ranges.patch: adjust credit card number ranges +- receipt_cardtype.patch: add new function for new Discover receipt + requirements +- docs.patch: update documentation about processing of different cards in + various countries + +(Closes: #814479) + + -- gregor herrmann Tue, 07 Jun 2016 21:58:27 +0200 + libbusiness-creditcard-perl (0.33-1) unstable; urgency=medium * Team upload. diff -Nru libbusiness-creditcard-perl-0.33/debian/patches/docs.patch libbusiness-creditcard-perl-0.33/debian/patches/docs.patch --- libbusiness-creditcard-perl-0.33/debian/patches/docs.patch 1970-01-01 01:00:00.0 +0100 +++ libbusiness-creditcard-perl-0.33/debian/patches/docs.patch 2016-06-26 14:51:25.0 +0200 @@ -0,0 +1,30 @@ +Description: Update POD to document mapping between card ranges and countries. +Origin: https://metacpan.org/release/Business-CreditCard, 0.34/0.35 +Bug-Debian: https://bugs.debian.org/814479 +Author: Ivan Kohler +Reviewed-by: gregor herrmann +Last-Update: 2016-06-07 + +--- a/CreditCard.pm b/CreditCard.pm +@@ -83,7 +83,7 @@ + other networks, in which one type of card is processed as another card type. + + By default, Business::CreditCard returns the type the card should be treated as +-in the US and Canada. You can change this to return the type the card should ++in the US. You can change this to return the type the card should + be treated as in a different country by setting + C<$Business::CreditCard::Country> to your two-letter country code. This + is probably what you want to determine if you accept the card, or which +@@ -99,9 +99,9 @@ + + =item Most Diner's club is now identified as Discover. (This supercedes the earlier identification of some Diner's club cards as MasterCard inside the US and Canada.) + +-=item JCB cards in the 3528-3589 range are identified as Discover inside the US and Canada. ++=item JCB cards in the 3528-3589 range are identified as
Bug#749357: libmakefile-parser-perl: FTBFS - tests fail
FTR: no reply from upstream since 2 years, despite some pings and preliminary patches sent by other pkg-perl team members. Given the popcon (installed = 22, vote = 2) and no reverse dependency, this package satisfies our team criteria for removal from the archive.
Bug#828046: ess: taking a *huge* time to load in emacs
On 26 June 2016 at 13:11, Julian Gilbey wrote: | On Fri, Jun 24, 2016 at 05:28:00AM -0500, Dirk Eddelbuettel wrote: | > | > On 24 June 2016 at 10:26, Julian Gilbey wrote: | > | Package: ess | > | Version: 16.04-2 | > | Severity: normal | > | | > | Hello Dirk, | > | | > | For some reason, ess has started taking a massive time to load at | > | emacs startup time: on my old machine, it is taking about two minutes. | > | (On my newer machine, the relative time differences are similar: | > | > Well I cannot confirm that as my home and work machines all behave well with | > it. Can you triage your .emacs down? | | Hello Dirk, | | I've tried it again (this time on my faster machine) with .emacs | skipped (using -q). I do have quite a few packages installed, but | they don't seem to be causing the difficulty. I can see the | initialisation just sitting at the line when it's loading 50ess, and I | have no idea why :-( | | Without ess installed: | | erdos:~ $ time emacs -batch -q -eval '(nil)' [...] | Symbol's function definition is void: nil | | real 0m0.682s | user 0m0.600s | sys 0m0.076s | | With ess installed: | | erdos:~ $ time emacs -batch -q -eval '(nil)' [...] | Symbol's function definition is void: nil | | real 0m6.675s | user 0m0.904s | sys 0m0.120s | | So ess is taking something like 90% of the initialisation time, | bizarrely. I can't really help you. I don't program elisp. I can forward this for you (you know how it goes) but I honestly think we should close this here and you refile at https://github.com/emacs-ess/ESS/issues I lurk there as they gave me write access just for the debian/ directory. I honestly cannot see any other solution than patient triaging, (un)installing one package at a time. Maybe starting in an empty Debian testing Docker container? Cheers, Dirk | Best wishes, | |Julian -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#828359: [Debian-med-packaging] Bug#828359: iva: FTBFS with openssl 1.1.0
Hi Kurt, thanks for the rebuild and for reporting this FTBFS. > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > OpenSSL this package fail to build. A log of that build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/iva_1.0.6+ds-1_amd64-20160529-1432 I was curious indeed when I saw iva fail, given that it does not use OpenSSL at all. Investigation of the build log led me to believe that the cause of this is a problem with Python’s multiprocessing module in pbuilder runs, which I suspect is connected to /dev/shm not being writable. This is a problem that also occurs in the rebuilds done by the Reproducible Builds folks [1]. > If you have problems making things work, feel free to contact us. I am not sure if I can just close this bug as it does not relate to OpenSSL and I should probably file a bug indicating this pbuilder associated issue. Thanks and best regards, Sascha [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/iva.html
Bug#828207: FTBFS: AttributeError: 'module' object has no attribute 'SubfieldBase'
Control: severity -1 important On Sun, 26 Jun 2016, Brian May wrote: > Guessing this might be a Django issue with 1.10~beta1-1: Yes, SubfieldBase was deprecated since 1.8 and it's removed in 1.10. 1.10 is not yet in sid, so reducing severity. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#800816: plinth: please make the build reproducible
On 06/26/2016 05:22 PM, Petter Reinholdtsen wrote: > Control: blocks -1 by 828220 > > [Sunil Mohan] >> Plinth 0.6-1 got uploaded. The original problem got resolved due to >> removal of code that generates TODO. However, we now have issue with >> PDF generated by dblatex. An ID and two dates are some binary changes >> are present. > > I had a look at the issue, and plinth calls xmlto which in turn call dblatex > to generate the PDF from the Docbook XML version. > > The effect is that the possible workarounds listed in > https://wiki.debian.org/ReproducibleBuilds/TimestampsInPDFGeneratedByLaTeX > > can not be implemented in plinth, but would have to be implemented in dblatex. > > I've filed https://bugs.debian.org/828220 > asking for dblatex to be > able to produce reproducable PDFs. > Last I tried, apart from the time issue, I believe I also got an issue with the way some images were generated into the resulting PDF. The generated image code would simply change from one run to another. IIRC, I worked around time issue using 'faketime': https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal . We could use that in our doc/Makefile if the other issues are resolved. -- Sunil signature.asc Description: OpenPGP digital signature
Bug#828629: nvidia-driver 355.11-2 (experimental, amd64) not installable
Package: nvidia-driver Version: 352.79-8 Severity: important Hi, this package is not installable due to missing nvidia-settings 355.11-2 (only 346.59-1 is available). Roman -- Package-specific info: uname -a: Linux kremator.cz 4.7.0-rc4-amd64 #1 SMP Debian 4.7~rc4-1~exp1 (2016-06-20) x86_64 GNU/Linux /proc/version: Linux version 4.7.0-rc4-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.7~rc4-1~exp1 (2016-06-20) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.79 Wed Jan 13 16:17:53 PST 2016 GCC version: gcc version 5.4.0 20160609 (Debian 5.4.0-4) lspci 'VGA compatible controller [0300]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107 [GeForce GTX 650] [10de:0fc6] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GTX650-DC-1GD5 [1043:8428] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [ 1362.478201] Modules linked in: saa7134_alsa nls_utf8 nls_cp437 vfat fat fuse tda1004x saa7134_dvb videobuf2_dvb dvb_core binfmt_misc zram zsmalloc lz4_compress tda827x snd_hda_codec_analog snd_hda_codec_generic tda8290 tuner snd_hda_codec_hdmi nvidia(POE) iTCO_wdt iTCO_vendor_support kvm_intel ir_lirc_codec lirc_dev snd_usb_audio kvm uvcvideo snd_usbmidi_lib irqbypass snd_rawmidi snd_seq_device usblp rc_asus_pc39 videobuf2_vmalloc saa7134 snd_hda_intel drm tveeprom rc_core snd_hda_codec v4l2_common videobuf2_dma_sg evdev videobuf2_memops videobuf2_v4l2 videobuf2_core serio_raw snd_hda_core pcspkr videodev snd_hwdep i2c_i801 media snd_pcm lpc_ich snd_timer mfd_core snd soundcore shpchp acpi_cpufreq hwmon_vid asus_atk0110 tpm_tis coretemp button tpm sg parport_pc ppdev lp parport autofs4 ext4 ecb glue_helper [ 2721.060058] Modules linked in: saa7134_alsa nls_utf8 nls_cp437 vfat fat fuse tda1004x saa7134_dvb videobuf2_dvb dvb_core binfmt_misc zram zsmalloc lz4_compress tda827x snd_hda_codec_analog snd_hda_codec_generic tda8290 tuner snd_hda_codec_hdmi nvidia(POE) iTCO_wdt iTCO_vendor_support kvm_intel ir_lirc_codec lirc_dev snd_usb_audio kvm uvcvideo snd_usbmidi_lib irqbypass snd_rawmidi snd_seq_device usblp rc_asus_pc39 videobuf2_vmalloc saa7134 snd_hda_intel drm tveeprom rc_core snd_hda_codec v4l2_common videobuf2_dma_sg evdev videobuf2_memops videobuf2_v4l2 videobuf2_core serio_raw snd_hda_core pcspkr videodev snd_hwdep i2c_i801 media snd_pcm lpc_ich snd_timer mfd_core snd soundcore shpchp acpi_cpufreq hwmon_vid asus_atk0110 tpm_tis coretemp button tpm sg parport_pc ppdev lp parport autofs4 ext4 ecb glue_helper [ 2721.076039] Modules linked in: saa7134_alsa nls_utf8 nls_cp437 vfat fat fuse tda1004x saa7134_dvb videobuf2_dvb dvb_core binfmt_misc zram zsmalloc lz4_compress tda827x snd_hda_codec_analog snd_hda_codec_generic tda8290 tuner snd_hda_codec_hdmi nvidia(POE) iTCO_wdt iTCO_vendor_support kvm_intel ir_lirc_codec lirc_dev snd_usb_audio kvm uvcvideo snd_usbmidi_lib irqbypass snd_rawmidi snd_seq_device usblp rc_asus_pc39 videobuf2_vmalloc saa7134 snd_hda_intel drm tveeprom rc_core snd_hda_codec v4l2_common videobuf2_dma_sg evdev videobuf2_memops videobuf2_v4l2 videobuf2_core serio_raw snd_hda_core pcspkr videodev snd_hwdep i2c_i801 media snd_pcm lpc_ich snd_timer mfd_core snd soundcore shpchp acpi_cpufreq hwmon_vid asus_atk0110 tpm_tis coretemp button tpm sg parport_pc ppdev lp parport autofs4 ext4 ecb glue_helper [ 2721.076208] Modules linked in: saa7134_alsa nls_utf8 nls_cp437 vfat fat fuse tda1004x saa7134_dvb videobuf2_dvb dvb_core binfmt_misc zram zsmalloc lz4_compress tda827x snd_hda_codec_analog snd_hda_codec_generic tda8290 tuner snd_hda_codec_hdmi nvidia(POE) iTCO_wdt iTCO_vendor_support kvm_intel ir_lirc_codec lirc_dev snd_usb_audio kvm uvcvideo snd_usbmidi_lib irqbypass snd_rawmidi snd_seq_device usblp rc_asus_pc39 videobuf2_vmalloc saa7134 snd_hda_intel drm tveeprom rc_core snd_hda_codec v4l2_common videobuf2_dma_sg evdev videobuf2_memops videobuf2_v4l2 videobuf2_core serio_raw snd_hda_core pcspkr videodev snd_hwdep i2c_i801 media snd_pcm lpc_ich snd_timer mfd_core snd soundcore shpchp acpi_cpufreq hwmon_vid asus_atk0110 tpm_tis coretemp button tpm sg parport_pc ppdev lp parport autofs4 ext4 ecb glue_helper [ 2721.076310] Modules linked in: saa7134_alsa nls_utf8 nls_cp437 vfat fat fuse tda1004x saa7134_dvb videobuf2_dvb dvb_core binfmt_misc zram zsmalloc lz4_compress tda827x snd_hda_codec_analog snd_hda_codec_generic tda8290 tuner snd_hda_codec_hdmi nvidia(POE) iTCO_wdt iTCO_vendor_support kvm_intel ir_lirc_codec lirc_dev snd_usb_audio kvm uvcvideo snd_usbmidi_lib irqbypass snd_rawmidi snd_seq_device usblp rc_asus_pc39 videobuf2_vmalloc saa7134 snd_hda_intel drm tveeprom rc_core snd_hda_codec v4l2_com
Bug#828627: uim: please make the build reproducible (locale)
Source: uim Version: 1:1.8.6+gh20160621.0.87bf935-1 Severity: wishlist Tags: patch upstream User: reproducible-bui...@lists.alioth.debian.org Usertags: locale X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, While working on the "reproducible builds" effort [1], we have noticed that 'uim' could not be built reproducibly. The attached patch sets the locale used to sort using LC_ALL instead of LANG (that is overwrote by LC_ALL), so that the order is fixed even if LC_ALL is set. Once applied, uim can be built reproducibly in our current experimental framework. Regards, Alexis Bienvenüe. [1]: https://wiki.debian.org/ReproducibleBuilds Description: Use LC_ALL instead of LANG bacause LC_ALL overwrites LANG. This makes the build reproducible. Author: Alexis Bienvenüe --- uim-1.8.6+gh20160621.0.87bf935.orig/tables/Makefile.am +++ uim-1.8.6+gh20160621.0.87bf935/tables/Makefile.am @@ -32,7 +32,7 @@ zm.scm: $(top_srcdir)/scm/zm.scm $(MAKE) $(AM_MAKEFLAGS) -C $(top_builddir)/replace && \ $(MAKE) $(AM_MAKEFLAGS) -C $(top_builddir)/uim sigscheme-combined && \ $(MAKE) $(AM_MAKEFLAGS) -C $(top_builddir)/uim uim-sh && \ - echo "(begin (load \"$<\") (for-each (lambda (key) (display (format \"~a ~W\n\" (apply string-append (caar key)) (cadr key `basename $< .scm`-rule))" | $(UIM_SH_ENV) $(UIM_SH) -b | grep -v "^#" | LANG=C sort > $@ + echo "(begin (load \"$<\") (for-each (lambda (key) (display (format \"~a ~W\n\" (apply string-append (caar key)) (cadr key `basename $< .scm`-rule))" | $(UIM_SH_ENV) $(UIM_SH) -b | grep -v "^#" | LC_ALL=C sort > $@ #endif clean-genscm:
Bug#828628: media-player-info: please make the build reproducible
Source: media-player-info Version: 22-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: fileordering X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that media-player-info could not be built reproducibly. It searches for .mpi files without sorting them. This leads to an unsorted order in .hwdb and .rules files. The attached patch fixes this. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch new file mode 100644 index 000..b742eca --- /dev/null +++ b/debian/patches/reproducible_build.patch @@ -0,0 +1,12 @@ +Author: Reiner Herrmann +Description: Sort list of mpi files to get reproducible rules/hwdb files + +--- a/media-players/Makefile.am b/media-players/Makefile.am +@@ -1,5 +1,5 @@ + mpidir = $(datadir)/media-player-info +-dist_mpi_DATA = $(shell find $(top_srcdir)/media-players -name "*.mpi" -printf "%p\n") ++dist_mpi_DATA = $(shell find $(top_srcdir)/media-players -name "*.mpi" -printf "%p\n" | LC_ALL=C sort) + + udevrulesdir = $(UDEV_DIR)/rules.d + nodist_udevrules_DATA = 40-usb-media-players.rules diff --git a/debian/patches/series b/debian/patches/series new file mode 100644 index 000..b2026fe --- /dev/null +++ b/debian/patches/series @@ -0,0 +1 @@ +reproducible_build.patch
Bug#811682: FTBFS with GCC 6: could not convert a from x to y
Control: tags -1 patch Hello, the attached patch fixes the reported compile error and also fixes the "narrowing conversion" errors that came up with g++-6. The package now builds with g++-6 (but it is not lintian-clean). Best, Gert From: Gert Wollny Date: Sun, 26 Jun 2016 13:25:00 +0200 Description: gcc 6.0 build fixes Bug: https://bugs.debian.org/811682 --- a/src/engine/common/View.cc +++ b/src/engine/common/View.cc @@ -291,7 +291,7 @@ } } - return false; + return nullptr; } bool --- a/src/backend/common/tfm/TFM.hh +++ b/src/backend/common/tfm/TFM.hh @@ -37,7 +37,7 @@ unsigned char face; const char* codingScheme; int designSize; -int checksum; +unsigned int checksum; unsigned int nDimensions; unsigned int nCharacters; }; @@ -52,7 +52,7 @@ struct Kerning { UChar8 index; -int value; +unsigned int value; }; struct Ligature @@ -67,7 +67,7 @@ UChar8 index; int width; int height; -int depth; +unsigned int depth; int italicCorrection; unsigned char nKernings; const Kerning* kerning; --- a/src/backend/common/ComputerModernShaper.cc +++ b/src/backend/common/ComputerModernShaper.cc @@ -578,7 +578,7 @@ }; #endif -static ComputerModernShaper::PlainChar cmsMap[] = +static ComputerModernShaper::PlainChar32 cmsMap[] = { { 0x007B, 0x66 }, // LEFT CURLY BRACKET { 0x007D, 0x67 }, // RIGHT CURLY BRACKET --- a/src/backend/common/StandardSymbolsShaper.hh +++ b/src/backend/common/StandardSymbolsShaper.hh @@ -32,20 +32,20 @@ struct HStretchyChar { Char16 ch; -Char8 normal; -Char8 left; -Char8 glue; -Char8 right; +UChar8 normal; +UChar8 left; +UChar8 glue; +UChar8 right; }; struct VStretchyChar { Char16 ch; -Char8 normal; -Char8 top; -Char8 glue; -Char8 middle; -Char8 bottom; +UChar8 normal; +UChar8 top; +UChar8 glue; +UChar8 middle; +UChar8 bottom; }; protected: --- a/src/backend/common/StandardSymbolsShaper.cc +++ b/src/backend/common/StandardSymbolsShaper.cc @@ -29,7 +29,7 @@ #include "ShapingContext.hh" struct GlyphMap { - Char8 index; + UChar8 index; Char16 ch; };
Bug#828046: ess: taking a *huge* time to load in emacs
On Fri, Jun 24, 2016 at 05:28:00AM -0500, Dirk Eddelbuettel wrote: > > On 24 June 2016 at 10:26, Julian Gilbey wrote: > | Package: ess > | Version: 16.04-2 > | Severity: normal > | > | Hello Dirk, > | > | For some reason, ess has started taking a massive time to load at > | emacs startup time: on my old machine, it is taking about two minutes. > | (On my newer machine, the relative time differences are similar: > > Well I cannot confirm that as my home and work machines all behave well with > it. Can you triage your .emacs down? Hello Dirk, I've tried it again (this time on my faster machine) with .emacs skipped (using -q). I do have quite a few packages installed, but they don't seem to be causing the difficulty. I can see the initialisation just sitting at the line when it's loading 50ess, and I have no idea why :-( Without ess installed: erdos:~ $ time emacs -batch -q -eval '(nil)' Loading 00debian-vars... Loading /etc/emacs/site-start.d/20apel.el (source)... Loading /etc/emacs/site-start.d/50a2ps.el (source)... Loading /etc/emacs/site-start.d/50asymptote.el (source)... Loading /etc/emacs/site-start.d/50auctex.el (source)... Loading /usr/share/emacs/site-lisp/auctex.el (source)... Loading /usr/share/emacs/site-lisp/preview-latex.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50devscripts-el.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Loading debian-ispell... Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)... Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)... Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Loading /etc/emacs/site-start.d/50ecb.el (source)... ECB 2.40 uses CEDET 2.0 (contains semantic 2.2, eieio 1.4, speedbar ). Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-intl-fonts.el (source)... Loading /etc/emacs/site-start.d/50epix.el (source)... Loading /etc/emacs/site-start.d/50festival.el (source)... Loading /etc/emacs/site-start.d/50flim.el (source)... Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)... Loading /etc/emacs/site-start.d/50gtypist.el (source)... Loading /etc/emacs/site-start.d/50haskell-mode.el (source)... Loading /usr/share/emacs24/site-lisp/haskell-mode/haskell-mode-autoloads.el (source)... Loading /etc/emacs/site-start.d/50lbdb.el (source)... Loading /etc/emacs/site-start.d/50lilypond-data.el (source)... Loading /etc/emacs/site-start.d/50mmm-mode.el (source)... Loading /etc/emacs/site-start.d/50noweb.el (source)... Loading /etc/emacs/site-start.d/50org-mode.el (source)... Loading /etc/emacs/site-start.d/50php-elisp.el (source)... Loading /etc/emacs/site-start.d/50proofgeneral.el (source)... Loading /usr/share/emacs24/site-lisp/proofgeneral/generic/proof-site.elc... Loading /etc/emacs24/site-start.d/50psgml-init.el (source)... Loading /etc/emacs/site-start.d/50python-docutils.el (source)... Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)... Loading /etc/emacs/site-start.d/50w3m-el.el (source)... Loading /etc/emacs/site-start.d/50yaml-mode.el (source)... Loading /etc/emacs/site-start.d/51debian-el.el (source)... Loading /etc/emacs/site-start.d/51semi.el (source)... Symbol's function definition is void: nil real 0m0.682s user 0m0.600s sys 0m0.076s With ess installed: erdos:~ $ time emacs -batch -q -eval '(nil)' Loading 00debian-vars... Loading /etc/emacs/site-start.d/20apel.el (source)... Loading /etc/emacs/site-start.d/50a2ps.el (source)... Loading /etc/emacs/site-start.d/50asymptote.el (source)... Loading /etc/emacs/site-start.d/50auctex.el (source)... Loading /usr/share/emacs/site-lisp/auctex.el (source)... Loading /usr/share/emacs/site-lisp/preview-latex.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50devscripts-el.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Loading debian-ispell... Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)... Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)... Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)... Loading /etc/emacs/site-start.d/50ecb.el (source)... ECB 2.40 uses CEDET 2.0 (contains semantic 2.2, eieio 1.4, speedbar ). Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)... Loading /etc/emacs/site-start.d/50emacs-intl-fonts.el (source)... Loading /etc/emacs/site-start.d/50epix.el (source)... Loading /etc/emacs/site-start.d/50ess.el (source)... Loading /etc/emacs/site-start.d/50festival.el (source)... Loading /etc/emacs/site-start.d/50flim.el (source)... Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)... Loading /etc/emacs/site-start.d/50gtypist.el (source)... Loading /etc/emacs/site-start.d/50haskell-mode.el (source)... Loading /usr/share/emacs24/site-lisp/haskell-mode/haskell-mode-autoloads
Bug#827899: vlc: rtsp stream crashes on AMD64 but works on i386
On 2016-06-23 18:43:17, ael wrote: > On Thu, Jun 23, 2016 at 10:24:27AM +0200, Sebastian Ramacher wrote: > > On 2016-06-22 10:40:32, ael wrote: > > > Package: src:vlc > > > Version: 2.2.4-2 > > > > Please remove libvdpau-va-gl1 or change the output method and try again. > > Yes. That now seems to work. But there are still some errors being > reported: For the remaining issues I'd recommend to contact upstream with a sample of the stream. See https://trac.videolan.org/vlc/. Please let us know the bug number so we can track the issue. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#828626: phpmyadmin: doesn't install
Package: phpmyadmin Version: 4:4.6.2-2 Severity: critical Justification: breaks unrelated software Dear Maintainer, The phpmyadmin package won't install and kind of breaks apt, using dpkg --configure -a to revert it. This is how the attempt to install it looks like. If it's worth mentioning, I'm using mariadb 10.1 with their sid repo. But things worked out well so far, the previous version is still up and running. Preparing to unpack .../phpmyadmin_4%3a4.6.3-1_all.deb ... Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. dpkg: warning: subprocess old pre-removal script returned error exit status 10 dpkg: trying script from the new package instead ... Determining localhost credentials from /etc/mysql/debian.cnf: succeeded. dpkg: error processing archive /var/cache/apt/archives/phpmyadmin_4%3a4.6.3-1_all.deb (--unpack): subprocess new pre-removal script returned error exit status 10 dbconfig-common: flushing administrative password *** Error in `/usr/bin/dpkg': munmap_chunk(): invalid pointer: 0x55dd69942005 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x71fc5)[0x7fba8d86afc5] /lib/x86_64-linux-gnu/libc.so.6(+0x77966)[0x7fba8d870966] /usr/bin/dpkg(+0x1ffb0)[0x55dd674d0fb0] /usr/bin/dpkg(+0x20409)[0x55dd674d1409] /usr/bin/dpkg(+0x2774a)[0x55dd674d874a] /usr/bin/dpkg(+0x16a37)[0x55dd674c7a37] /usr/bin/dpkg(+0x16c35)[0x55dd674c7c35] /usr/bin/dpkg(+0x16e7d)[0x55dd674c7e7d] /usr/bin/dpkg(+0xa207)[0x55dd674bb207] /usr/bin/dpkg(+0x1feeb)[0x55dd674d0eeb] /usr/bin/dpkg(+0x200f1)[0x55dd674d10f1] /usr/bin/dpkg(+0x9c88)[0x55dd674bac88] /usr/bin/dpkg(+0x6659)[0x55dd674b7659] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fba8d8195f0] /usr/bin/dpkg(+0x6769)[0x55dd674b7769] === Memory map: 55dd674b1000-55dd674f5000 r-xp 08:05 655675 /usr/bin/dpkg 55dd676f5000-55dd676f8000 r--p 00044000 08:05 655675 /usr/bin/dpkg 55dd676f8000-55dd676f9000 rw-p 00047000 08:05 655675 /usr/bin/dpkg 55dd676f9000-55dd6790d000 rw-p 00:00 0 55dd697f2000-55dd6bd1a000 rw-p 00:00 0 [heap] 7fba8c714000-7fba8c72a000 r-xp 08:05 5902353 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fba8c72a000-7fba8c929000 ---p 00016000 08:05 5902353 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fba8c929000-7fba8c92a000 rw-p 00015000 08:05 5902353 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fba8c92a000-7fba8c935000 r-xp 08:05 5898683 /lib/x86_64-linux-gnu/libnss_files-2.22.so 7fba8c935000-7fba8cb34000 ---p b000 08:05 5898683 /lib/x86_64-linux-gnu/libnss_files-2.22.so 7fba8cb34000-7fba8cb35000 r--p a000 08:05 5898683 /lib/x86_64-linux-gnu/libnss_files-2.22.so 7fba8cb35000-7fba8cb36000 rw-p b000 08:05 5898683 /lib/x86_64-linux-gnu/libnss_files-2.22.so 7fba8cb36000-7fba8cb3c000 rw-p 00:00 0 7fba8cb3c000-7fba8cb46000 r-xp 08:05 5898685 /lib/x86_64-linux-gnu/libnss_nis-2.22.so 7fba8cb46000-7fba8cd46000 ---p a000 08:05 5898685 /lib/x86_64-linux-gnu/libnss_nis-2.22.so 7fba8cd46000-7fba8cd47000 r--p a000 08:05 5898685 /lib/x86_64-linux-gnu/libnss_nis-2.22.so 7fba8cd47000-7fba8cd48000 rw-p b000 08:05 5898685 /lib/x86_64-linux-gnu/libnss_nis-2.22.so 7fba8cd48000-7fba8cd5d000 r-xp 08:05 5898680 /lib/x86_64-linux-gnu/libnsl-2.22.so 7fba8cd5d000-7fba8cf5c000 ---p 00015000 08:05 5898680 /lib/x86_64-linux-gnu/libnsl-2.22.so 7fba8cf5c000-7fba8cf5d000 r--p 00014000 08:05 5898680 /lib/x86_64-linux-gnu/libnsl-2.22.so 7fba8cf5d000-7fba8cf5e000 rw-p 00015000 08:05 5898680 /lib/x86_64-linux-gnu/libnsl-2.22.so 7fba8cf5e000-7fba8cf6 rw-p 00:00 0 7fba8cf6-7fba8cf67000 r-xp 08:05 5898681 /lib/x86_64-linux-gnu/libnss_compat-2.22.so 7fba8cf67000-7fba8d166000 ---p 7000 08:05 5898681 /lib/x86_64-linux-gnu/libnss_compat-2.22.so 7fba8d166000-7fba8d167000 r--p 6000 08:05 5898681 /lib/x86_64-linux-gnu/libnss_compat-2.22.so 7fba8d167000-7fba8d168000 rw-p 7000 08:05 5898681 /lib/x86_64-linux-gnu/libnss_compat-2.22.so 7fba8d168000-7fba8d18 r-xp 08:05 5898688 /lib/x86_64-linux-gnu/libpthread-2.22.so 7fba8d18-7fba8d37f000 ---p 00018000 08:05 5898688 /lib/x86_64-linux-gnu/libpthread-2.22.so 7fba8d37f000-7fba8d38 r--p 00017000 08:05 5898688 /lib/x86_64-linux-gnu/libpthread-2.22.so 7fba8d38-7fba8d381000 rw-p 00018000 08:05 5898688 /lib/x86_64-linux-gnu/libpthread-2.22.so 7fba8d381000-7fba8d385000 rw-p 00:00 0 7fba8d385000-7fba8d387000 r-xp 0
Bug#828476: open-vm-tools: FTBFS with openssl 1.1.0
On Sun, Jun 26, 2016 at 02:05:15PM +0200, Bernd Zeimetz wrote: > Hi Kurt, > > I've forwarded the issue to the vmware guys. Do you have an ETA of 1.1.0 > in unstable? Not yet. The upstream release is currently aiming for the 7th of July, but it will also depend on the release team. Kurt
Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0
On Sun, Jun 26, 2016 at 12:20:33PM +0100, Thomas Leonard wrote: > On 26 June 2016 at 11:24, Kurt Roeckx wrote: > > Hi, > > > > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > > OpenSSL this package fail to build. A log of that build can be found at: > > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zeroinstall-injector_2.10-2_amd64-20160530-2117 > > > > On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various > > of the > > reasons why it might fail. There are also updated man pages at > > https://www.openssl.org/docs/manmaster/ that should contain useful > > information. > > > > There is a libssl-dev package available in experimental that contains a > > recent > > snapshot, I suggest you try building against that to see if everything > > works. > > > > If you have problems making things work, feel free to contact us. > > The problem appears to be in ocaml-ssl. See: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828462 So should it just be merged, or do you want to have 1 block the other? Kurt
Bug#828476: open-vm-tools: FTBFS with openssl 1.1.0
Hi Kurt, I've forwarded the issue to the vmware guys. Do you have an ETA of 1.1.0 in unstable? Thanks, Bernd On 06/26/2016 12:23 PM, Kurt Roeckx wrote: > Source: open-vm-tools > Version: 10.0.7-3227872-2 > Severity: important > Control: block 827061 by -1 > > Hi, > > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > OpenSSL this package fail to build. A log of that build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/open-vm-tools_10.0.7-3227872-2_amd64-20160529-1501 > > On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of > the > reasons why it might fail. There are also updated man pages at > https://www.openssl.org/docs/manmaster/ that should contain useful > information. > > There is a libssl-dev package available in experimental that contains a recent > snapshot, I suggest you try building against that to see if everything works. > > If you have problems making things work, feel free to contact us. > > > Kurt > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#828625: nethack-console: wizard mode permanently identify does not works on armhf port
Package: nethack-console Version: 3.6.0-3 Severity: normal Tags: patch Dear Maintainer, 1. This bug is only found on armhf port; it is not found on amd64 port. It can be reproduced on a chroot Debian system on a ARMv7 smart phone and on a full Debian system in a QEMU virtual machine. 2. Method of reproduce and behavior of this bug 1) Start a wizard mode game: $ sudo /usr/games/nethack-console -D 2) Optional: Press ^W, then press Enter to wizard mode wish some random items; these created items are not fully identified. 3) Press ^I, then the Debug Identify menu, which shows the character's inventory with all items temporarily identified, will appear. 4) Press ^I again, then the Debug Identify menu disapeared, and a) the expected outcome: the game show "You have already identified all of your possessions." , if all items are already identified; or the game show full identify information of items and those items will be permanently identified, if there are some unidentified items in the inventory. b) the buggy outcome: nothing happen and unidentified items are still unidentified. 3. Possible cause In the function display_pickinv(), a special menu item is added to the Debug Identify menu; the identifier of this item is set to -1(src/invent.c:2083): any.a_char = -1; The type of any.a_char is char(include/wintype.h:16): char a_char; When ^I is pressed in the Debug Identify menu, the identifier will be returned by display_pickinv(). And wiz_identify() will check whether the return value of display_pickinv() equals -1(src/cmd.c:595): if (display_inventory((char *) 0, TRUE) == -1) then determine to fully identify all items or do nothing. However the type char is unsigned by default on arm port. "any.a_char = -1;" will set any.a_char to 255 actually on arm port(this can be verified by using gdb), so that above if statement will never success, and the permanent wizard identify will never be performed. Since all involved codes are all in files under src/ and include/ dirs, it seems that this bug affects not only nethack-console, but also nethack-x11 and nethack-lisp. As I did not test those two favors, this may not be true. 4. Demonstration patch After apply the attached patch, the bug disappeared. Please consider examine and apply it. Regards, Jun MO -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: armhf (armv7l) Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nethack-console depends on: ii libc6 2.22-12 ii libncurses5 6.0+20160319-2+b1 ii libtinfo5 6.0+20160319-2+b1 ii nethack-common 3.6.0-3 nethack-console recommends no packages. nethack-console suggests no packages. -- no debconf information Description: fix permanently identify bug The return value of display_inventory() is from a type char value; since the type char is unsigned on port arm by default, the if statement will never success and identify will not be commited. --- a/src/cmd.c +++ b/src/cmd.c @@ -592,7 +592,7 @@ { if (wizard) { iflags.override_ID = (int) cmd_from_func(wiz_identify); -if (display_inventory((char *) 0, TRUE) == -1) +if (display_inventory((char *) 0, TRUE) == (char) -1) identify_pack(0, FALSE); iflags.override_ID = 0; } else
Bug#828569: tcpdump: FTBFS with openssl 1.1.0
Hi Kurt, On Sun, Jun 26, 2016 at 12:24:22PM +0200, Kurt Roeckx wrote: > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > OpenSSL this package fail to build. A log of that build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/tcpdump_4.7.4-1_amd64-20160529-1543 Thanks for the report. I was already tracking this, there is a fix in upstream Git but a new upstream release is supposed to be released next week so I think I will wait for that. Cheers, -- Romain Francoise https://people.debian.org/~rfrancoise/
Bug#828611: Fwd: Bug#828611: xymon: Fails to build from source with OpenSSL 1.1.0
Hi, this has been reported in Debian at https://bugs.debian.org/828611 - Forwarded message from Kurt Roeckx - Date: Sun, 26 Jun 2016 12:24:54 +0200 From: Kurt Roeckx To: sub...@bugs.debian.org Subject: Bug#828611: xymon: FTBFS with openssl 1.1.0 Reply-To: Kurt Roeckx , 828...@bugs.debian.org Source: xymon Version: 4.3.27-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xymon_4.3.27-1_amd64-20160529-1558 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt - End forwarded message - Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#828434: megatools: FTBFS with openssl 1.1.0
Control: forwarded -1 https://github.com/megous/megatools/issues/208 On Sun, Jun 26, 2016 at 12:23:01PM +0200, Kurt Roeckx wrote: > OpenSSL 1.1.0 is about to released. During a rebuild of all > packages using OpenSSL this package fail to build. A log of that > build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/megatools_1.9.97-1_amd64-20160529-1450 This has been fixed upstream and will be available in the next stable release. If the next release takes too much I'll try to have the patch backported. Berto
Bug#800816: plinth: please make the build reproducible
Control: blocks -1 by 828220 [Sunil Mohan] > Plinth 0.6-1 got uploaded. The original problem got resolved due to > removal of code that generates TODO. However, we now have issue with > PDF generated by dblatex. An ID and two dates are some binary changes > are present. I had a look at the issue, and plinth calls xmlto which in turn call dblatex to generate the PDF from the Docbook XML version. The effect is that the possible workarounds listed in https://wiki.debian.org/ReproducibleBuilds/TimestampsInPDFGeneratedByLaTeX > can not be implemented in plinth, but would have to be implemented in dblatex. I've filed https://bugs.debian.org/828220 > asking for dblatex to be able to produce reproducable PDFs. -- Happy hacking Petter Reinholdtsen
Bug#817711: uudeview: Removal of debhelper compat 4
Control: tags -1 patch On 2016-03-09 ni...@thykier.net wrote: > Source: uudeview > Severity: important > Usertags: compat-4-removal > Hi, > The package uudeview uses debhelper with a compat level of 4, > which is deprecated and scheduled for removal. > * Please bump the debhelper compat at your earliest convenience. >on the 15th of June. >- Compat 9 is recommended >- Compat 5 is the bare minimum >- If the package has been relying on dh_install being lenient about > missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1]. > * Compat level 4 will be removed on the first debhelper upload after >the 15th of June. [...] There is a trivial fix ... echo 5 > debian/compat ... generates a identical package. I have also locally upgraded the packaging to compat 9 (with dh wrapper) but will not upload as NMU. Afaiu the package might be orphaned, then this would be eligible for a QA upload. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#825718: Fwd: Bug#825718: forensics-all: hdd spin down upon install
Re fwd'ing only to 825718 since unsure anything else to consider ? i can confirm the behaviour of hdd spin down constantly computer left on over night, hdd constantly spins up/down when hdd spin-down set to 129 in 'disks' behaviour still occurs any suggestions appreciated. Forwarded Message Subject: Re: Bug#825718: forensics-all: hdd spin down upon install Date: Mon, 13 Jun 2016 22:48:13 +1000 From: Fulano Diego Perez To: 825718-qu...@bugs.debian.org, 825718-submit...@bugs.debian.org > Complementing the previous message, I will wait 15 days for a response > from you, then will close this bug. > > Regards, > im not sure where to file the bug - with the meta package or hdparm either forensics includes a config for hdparm or hdparm does...i dont know i cannot think of any other forensics package that may be doing this ill wait for you to decide if this bug should be re-assigned hdparm
Bug#828624: samba: samba-ad-dc.service shouldn't be enabled by default
Package: samba Version: 2:4.4.4+dfsg-1 Severity: serious File: /lib/systemd/system/samba-ad-dc.service Hi, With the newest version the installation of samba package is failing because of the samba-ad-dc.service service. In the logs I see the following message: [2016/06/26 13:15:32.377822, 0] ../source4/smbd/server.c:373(binary_smbd_main) samba version 4.4.4-Debian started. Copyright Andrew Tridgell and the Samba Team 1992-2016 [2016/06/26 13:15:32.414489, 0] ../source4/smbd/server.c:472(binary_smbd_main) At this time the 'samba' binary should only be used for either: 'server role = active directory domain controller' or to access the ntvfs file server with 'server services = +smb' or the rpc proxy with 'dcerpc endpoint servers = remote' You should start smbd/nmbd/winbindd instead for domain member and standalone file server tasks [2016/06/26 13:15:32.414586, 0] ../lib/util/become_daemon.c:111(exit_daemon) STATUS=daemon failed to start: Samba detected misconfigured 'server role' and exited. Check logs for details, error code 22 IMVO, the service shouldn't be enabled and started in default installations. That would probably require some extra documentation in the README.Debian too Regards, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages samba depends on: ii adduser 3.114 ii dpkg 1.18.7 ii init-system-helpers 1.35 ii libbsd0 0.8.3-1 ii libc62.22-12 ii libldb1 2:1.1.26-1 ii libpam-modules 1.1.8-3.3 ii libpam-runtime 1.1.8-3.3 ii libpopt0 1.16-10 ii libpython2.7 2.7.12~rc1-2 ii libtalloc2 2.1.6-1 ii libtdb1 1.3.9-1 ii libtevent0 0.9.28-1 ii libwbclient0 2:4.4.4+dfsg-1 ii lsb-base 9.20160601 ii procps 2:3.3.11-3 ii python 2.7.11-2 ii python-dnspython 1.14.0-1 ii python-samba 2:4.4.4+dfsg-1 pn python2.7:any ii samba-common 2:4.4.4+dfsg-1 ii samba-common-bin 2:4.4.4+dfsg-1 ii samba-libs 2:4.4.4+dfsg-1 ii tdb-tools1.3.9-1 ii update-inetd 4.43 Versions of packages samba recommends: ii attr1:2.4.47-2 ii logrotate 3.8.7-2 ii samba-dsdb-modules 2:4.4.4+dfsg-1 ii samba-vfs-modules 2:4.4.4+dfsg-1 Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools ii ntp1:4.2.8p8+dfsg-1 pn smbldap-tools pn ufw pn winbind -- no debconf information
Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0
On 26 June 2016 at 11:24, Kurt Roeckx wrote: > Hi, > > OpenSSL 1.1.0 is about to released. During a rebuild of all packages using > OpenSSL this package fail to build. A log of that build can be found at: > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zeroinstall-injector_2.10-2_amd64-20160530-2117 > > On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of > the > reasons why it might fail. There are also updated man pages at > https://www.openssl.org/docs/manmaster/ that should contain useful > information. > > There is a libssl-dev package available in experimental that contains a recent > snapshot, I suggest you try building against that to see if everything works. > > If you have problems making things work, feel free to contact us. The problem appears to be in ocaml-ssl. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828462 -- talex5 (GitHub/Twitter)http://roscidus.com/blog/ GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA
Bug#828223: mvtnorm: FTBFS: dh_clean: Please specify the compatibility level in debian/compat
On 26 June 2016 at 06:00, Dirk Eddelbuettel wrote: | | On 26 June 2016 at 10:37, Chris Lamb wrote: | | Source: mvtnorm | | Version: 1.0-5-1 | | Severity: serious | | Justification: fails to build from source | | User: reproducible-bui...@lists.alioth.debian.org | | Usertags: ftbfs | | X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org | | | | Dear Maintainer, | | | | mvtnorm fails to build from source in unstable/amd64: | | Already fixed in 1.0-5-2. Which I prepared yesterday, along with a bunch of others, but not uploaded by oversight. Now corrected. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#828623: manpages-fr-extra: shutdown, reboot and like should translation should come from systemd one
Package: manpages-fr-extra Version: 20151231 Severity: normal Hi, Now that systemd is the default initsystem on debian, shouldn't the French shutdown, reboot, halt, poweroff manpages be translated from that source package? Regards, Laurent Bigonville -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) manpages-fr-extra depends on no packages. Versions of packages manpages-fr-extra recommends: ii manpages-fr 3.65d1p1-1 Versions of packages manpages-fr-extra suggests: ii man-db [man-browser] 2.7.5-1 pn manpages-fr-dev -- no debconf information
Bug#814711: Garbled graphics in Renoise application
Problem seems to be fixed at some point before 1.18.3-1 Please close this bug.
Bug#828622: xul-ext-greasemonkey: unable to manage scripts since Iceweasel -> Firefox ESR transition
Package: xul-ext-greasemonkey Version: 2.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, The greasemonkey plugin has suddenly stopped working. I believe this to have happened after upgrading to debian 8.5 where Iceweasel was upgraded and is now Firefox ESR. How it does not work: * its menu "Manage user scripts..." opens "about:addons instead * its menu "New user script" does nothing * button to install on websites with scripts to install, such as greasyfork.org, no longer works and firefox displays the source of the script instead. In addition, previously enabled scripts have been disabled (or just no longer work but since the script manager is not accessible I can't check the issue). Carnë -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-greasemonkey depends on: ii iceweasel 45.2.0esr-1~deb8u1 xul-ext-greasemonkey recommends no packages. xul-ext-greasemonkey suggests no packages. -- no debconf information
Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0
Source: zeroinstall-injector Version: 2.10-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zeroinstall-injector_2.10-2_amd64-20160530-2117 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828615: yate: FTBFS with openssl 1.1.0
Source: yate Version: 5.4.0-1-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/yate_5.4.0-1-1_amd64-20160529-1559 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828621: opencolorio: FTBFS: ! Undefined control sequence.
Source: opencolorio Version: 1.0.9~dfsg0-5 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, opencolorio fails to build from source in unstable/amd64: [..] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:119: WARNING: autodoc: failed to import function u'SetCurrentConfig' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:121: WARNING: autodoc: failed to import function u'SetLoggingLevel' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:126: WARNING: autodoc: failed to import class u'Config' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:133: WARNING: autodoc: failed to import class u'ColorSpace' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:140: WARNING: autodoc: failed to import class u'Look' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:147: WARNING: autodoc: failed to import class u'Processor' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonAPI.rst:154: WARNING: autodoc: failed to import class u'Context' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonTransforms.rst:17: WARNING: autodoc: failed to import class u'Transform' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonTransforms.rst:30: WARNING: autodoc: failed to import class u'AllocationTransform' from module u'PyOpenColorIO'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/sphinx/ext/autodoc.py", line 518, in import_object __import__(self.modname) ImportError: No module named PyOpenColorIO /home/lamby/temp/cdt.20160626122618.uMWLWemApZ.opencolorio/opencolorio-1.0.9~dfsg0/debian/cmake/docs/developers/bindings/PythonTransforms.rst:48: WARNING: autodoc: failed to import clas
Bug#828614: yara: FTBFS with openssl 1.1.0
Source: yara Version: 3.4.0+dfsg-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/yara_3.4.0+dfsg-2_amd64-20160529-1559 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828620: zorp: FTBFS with openssl 1.1.0
Source: zorp Version: 3.9.5-7 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zorp_3.9.5-7_amd64-20160529-1600 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828619: znc: FTBFS with openssl 1.1.0
Source: znc Version: 1.6.3-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/znc_1.6.3-2_amd64-20160529-1600 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828616: yubico-piv-tool: FTBFS with openssl 1.1.0
Source: yubico-piv-tool Version: 1.0.3-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/yubico-piv-tool_1.0.3-1_amd64-20160529-1559 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828617: zeroc-ice: FTBFS with openssl 1.1.0
Source: zeroc-ice Version: 3.5.1-6.4 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/zeroc-ice_3.5.1-6.4_amd64-20160529-1600 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828613: yapet: FTBFS with openssl 1.1.0
Source: yapet Version: 1.0-7 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/yapet_1.0-7_amd64-20160529-1558 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828605: xchat-gnome: FTBFS with openssl 1.1.0
Source: xchat-gnome Version: 0.30.0~git20131003.d20b8d-4 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xchat-gnome_0.30.0~git20131003.d20b8d-4_amd64-20160529-1554 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828609: xmms2: FTBFS with openssl 1.1.0
Source: xmms2 Version: 0.8+dfsg-16 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xmms2_0.8+dfsg-16_amd64-20160529-1557 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828607: xml-security-c: FTBFS with openssl 1.1.0
Source: xml-security-c Version: 1.7.3-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xml-security-c_1.7.3-1_amd64-20160529-1555 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828612: yadifa: FTBFS with openssl 1.1.0
Source: yadifa Version: 2.1.6-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/yadifa_2.1.6-1_amd64-20160529-1558 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828611: xymon: FTBFS with openssl 1.1.0
Source: xymon Version: 4.3.27-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xymon_4.3.27-1_amd64-20160529-1558 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828608: xmltooling: FTBFS with openssl 1.1.0
Source: xmltooling Version: 1.5.6-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xmltooling_1.5.6-2_amd64-20160529-1555 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828604: xca: FTBFS with openssl 1.1.0
Source: xca Version: 1.3.2-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xca_1.3.2-1_amd64-20160529-1554 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828610: xrdp: FTBFS with openssl 1.1.0
Source: xrdp Version: 0.6.1-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xrdp_0.6.1-2_amd64-20160529-1558 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828606: xmlsec1: FTBFS with openssl 1.1.0
Source: xmlsec1 Version: 1.2.20-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/xmlsec1_1.2.20-2_amd64-20160529-1555 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828603: wvstreams: FTBFS with openssl 1.1.0
Source: wvstreams Version: 4.6.1-8 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/wvstreams_4.6.1-8_amd64-20160529-1553 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828593: virtualbox: FTBFS with openssl 1.1.0
Source: virtualbox Version: 5.0.20-dfsg-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/virtualbox_5.0.20-dfsg-2_amd64-20160530-2117 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828597: webauth: FTBFS with openssl 1.1.0
Source: webauth Version: 4.7.0-3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/webauth_4.7.0-3_amd64-20160529-1551 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828599: wget: FTBFS with openssl 1.1.0
Source: wget Version: 1.17.1-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/wget_1.17.1-2_amd64-20160529-1551 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828602: wrk: FTBFS with openssl 1.1.0
Source: wrk Version: 4.0.1-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/wrk_4.0.1-2_amd64-20160529-1553 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828595: voms: FTBFS with openssl 1.1.0
Source: voms Version: 2.0.13-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/voms_2.0.13-1_amd64-20160529-1550 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828592: vboot-utils: FTBFS with openssl 1.1.0
Source: vboot-utils Version: 0~20121212-3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/vboot-utils_0~20121212-3_amd64-20160529-1548 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828598: webcit: FTBFS with openssl 1.1.0
Source: webcit Version: 902-dfsg-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/webcit_902-dfsg-1_amd64-20160529-1551 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828601: wpa: FTBFS with openssl 1.1.0
Source: wpa Version: 2.3-2.3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/wpa_2.3-2.3_amd64-20160529-1552 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828596: vtun: FTBFS with openssl 1.1.0
Source: vtun Version: 3.0.3-2.2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/vtun_3.0.3-2.2_amd64-20160529-1551 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828600: witty: FTBFS with openssl 1.1.0
Source: witty Version: 3.3.5+dfsg-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/witty_3.3.5+dfsg-1_amd64-20160529-1552 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828594: virtuoso-opensource: FTBFS with openssl 1.1.0
Source: virtuoso-opensource Version: 6.1.6+dfsg2-3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/virtuoso-opensource_6.1.6+dfsg2-3_amd64-20160529-1549 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828588: utopia-documents: FTBFS with openssl 1.1.0
Source: utopia-documents Version: 2.4.4-2.1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/utopia-documents_2.4.4-2.1_amd64-20160529-1548 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828591: validns: FTBFS with openssl 1.1.0
Source: validns Version: 0.8-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/validns_0.8-2_amd64-20160529-1548 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828587: urweb: FTBFS with openssl 1.1.0
Source: urweb Version: 20160213+dfsg-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/urweb_20160213+dfsg-1_amd64-20160529-1547 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828585: unworkable: FTBFS with openssl 1.1.0
Source: unworkable Version: 0.53-3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/unworkable_0.53-3_amd64-20160529-1547 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828589: uw-imap: FTBFS with openssl 1.1.0
Source: uw-imap Version: 2007f~dfsg-4 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/uw-imap_2007f~dfsg-4_amd64-20160529-1548 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828590: uwsgi: FTBFS with openssl 1.1.0
Source: uwsgi Version: 2.0.12-7 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/uwsgi_2.0.12-7_amd64-20160529-1548 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828586: up-imapproxy: FTBFS with openssl 1.1.0
Source: up-imapproxy Version: 1.2.7-1.1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/up-imapproxy_1.2.7-1.1_amd64-20160529-1547 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828584: unbound: FTBFS with openssl 1.1.0
Source: unbound Version: 1.5.8-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/unbound_1.5.8-1_amd64-20160529-1547 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828583: uhub: FTBFS with openssl 1.1.0
Source: uhub Version: 0.4.1-3 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/uhub_0.4.1-3_amd64-20160529-1547 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828582: uget: FTBFS with openssl 1.1.0
Source: uget Version: 2.0.7-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/uget_2.0.7-1_amd64-20160529-1546 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828579: trousers: FTBFS with openssl 1.1.0
Source: trousers Version: 0.3.13-4 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/trousers_0.3.13-4_amd64-20160529-1546 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828577: tpm-tools: FTBFS with openssl 1.1.0
Source: tpm-tools Version: 1.3.8-2 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/tpm-tools_1.3.8-2_amd64-20160530-2116 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828576: tor: FTBFS with openssl 1.1.0
Source: tor Version: 0.2.7.6-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/tor_0.2.7.6-1_amd64-20160529-1545 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828581: turnserver: FTBFS with openssl 1.1.0
Source: turnserver Version: 0.7.3-4 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/turnserver_0.7.3-4_amd64-20160529-1546 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828578: trafficserver: FTBFS with openssl 1.1.0
Source: trafficserver Version: 6.1.1-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/trafficserver_6.1.1-1_amd64-20160529-1545 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt
Bug#828580: trustedqsl: FTBFS with openssl 1.1.0
Source: trustedqsl Version: 2.2.1-1 Severity: important Control: block 827061 by -1 Hi, OpenSSL 1.1.0 is about to released. During a rebuild of all packages using OpenSSL this package fail to build. A log of that build can be found at: https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/trustedqsl_2.2.1-1_amd64-20160529-1546 On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of the reasons why it might fail. There are also updated man pages at https://www.openssl.org/docs/manmaster/ that should contain useful information. There is a libssl-dev package available in experimental that contains a recent snapshot, I suggest you try building against that to see if everything works. If you have problems making things work, feel free to contact us. Kurt