Bug#828635: libnet-tclink-perl: please make the build reproducible

[Reiner Herrmann]

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)

[Jérôme Lebleu]

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

[Elrond]

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

[Joseph Vaughan]

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

[Luca Boccassi]

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

[Chris Lamb]

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 

Bug#789381: libpoe-api-peek-perl: FTBFS with perl 5.22: test failures

[intrigeri]

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

[intrigeri]

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

[Russell Coker]

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#791636: higan: Load and save state do not work without having focus

[Tobias Hansen]

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#828632: tidy-html5: FTBFS on !linux archs

[Pino Toscano]

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=kfreebsd-amd64=1%3A5.2.0-1=1466341667
[2] 
https://buildd.debian.org/status/fetch.php?pkg=tidy-html5=kfreebsd-i386=1%3A5.2.0-1=1466336333
[3] 
https://buildd.debian.org/status/fetch.php?pkg=tidy-html5=hurd-i386=1%3A5.2.0-1=1466342177
[4] https://github.com/htacg/tidy-html5/pull/423

Thanks,
-- 
Pino

Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim

[Sean Whitton]

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

[Petter Reinholdtsen]

[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

[Matteo Croce]

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

[Pino Toscano]

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

[gregor herrmann]

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=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.

Bug#749357: libmakefile-parser-perl: FTBFS - tests fail

[intrigeri]

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

[Dirk Eddelbuettel]

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

[Sascha Steinbiss]

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'

[Raphael Hertzog]

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

[Sunil Mohan Adapa]

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

[Roman Horn�k]

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 

Bug#828627: uim: please make the build reproducible (locale)

[Alexis Bienvenüe]

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

[Reiner Herrmann]

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

[Gert Wollny]

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

[Julian Gilbey]

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 

Bug#827899: vlc: rtsp stream crashes on AMD64 but works on i386

[Sebastian Ramacher]

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

[Mircea Toader]

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  

Bug#828476: open-vm-tools: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Bernd Zeimetz]

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

[Mo Jun]

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

[Romain Francoise]

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

[Axel Beckert]

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

[Alberto Garcia]

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

[Petter Reinholdtsen]

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

[Andreas Metzler]

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

[Fulano Diego Perez]

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

[Laurent Bigonville]

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

[Thomas Leonard]

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

[Dirk Eddelbuettel]

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

[Laurent Bigonville]

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

[vitaminx]

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

[carandraug]

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#828615: yate: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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.

[Chris Lamb]

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 

Bug#828618: zeroinstall-injector: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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#828614: yara: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828607: xml-security-c: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828605: xchat-gnome: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828611: xymon: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828576: tor: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828579: trousers: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

[Kurt Roeckx]

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#828580: trustedqsl: FTBFS with openssl 1.1.0

[Kurt Roeckx]

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

Bug#828575: tomcat-native: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tomcat-native
Version: 1.2.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/tomcat-native_1.2.7-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#828574: tntnet: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tntnet
Version: 2.2.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/tntnet_2.2.1-2_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#828573: tlsdate: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tlsdate
Version: 0.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/tlsdate_0.0.13-1_amd64-20160529-1544

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#828571: tinc: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tinc
Version: 1.0.28-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/tinc_1.0.28-1_amd64-20160529-1544

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#828572: tkrat: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tkrat
Version: 2.2cvs20100105-true-dfsg-6
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/tkrat_2.2cvs20100105-true-dfsg-6_amd64-20160529-1544

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#828567: tcltrf: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tcltrf
Version: 2.1.4-dfsg3-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/tcltrf_2.1.4-dfsg3-1_amd64-20160529-1543

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#828568: tcpcrypt: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tcpcrypt
Version: 0.4-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/tcpcrypt_0.4-4_amd64-20160529-1543

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#828570: tcpflow: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tcpflow
Version: 1.4.5+repack1-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/tcpflow_1.4.5+repack1-1_amd64-20160529-1544

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#828569: tcpdump: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: tcpdump
Version: 4.7.4-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/tcpdump_4.7.4-1_amd64-20160529-1543

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#828564: sx: FTBFS with openssl 1.1.0

[Kurt Roeckx]

Source: sx
Version: 2.0+ds-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/sx_2.0+ds-2_amd64-20160529-1542

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