On 2018-10-31 18:41:06 [-0400], Theodore Y. Ts'o wrote:
> On Wed, Oct 31, 2018 at 11:21:59AM +0000, Sebastian Andrzej Siewior wrote:
> > On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o"
> > wrote:
> > >
> > >So it's complicated. It's not a
control: reassign -1 src:burp
On 2018-11-01 18:56:30 [+0100], Antoine Sirinelli wrote:
> I have a setup with a burp backup server running with an up to date
> stretch distribution. The backup clients are running on either stretch
> or buster workstation. Since the recent update of libssl1.1 from
On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o" wrote:
>
>So it's complicated. It's not a binary trusted/untrusted sort of
>thing.
What about RNDRESEEDCRNG? Would it be reasonable to issue it after writing the
seed as part of the boot process?
>Cheers,
>
>
On 2018-10-29 23:33:34 [+0100], Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > > So I believe this is not an openssl issue, but something in the
> > >
On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> So I believe this is not an openssl issue, but something in the
> order that the kernel's RNG is initialized and openssh is started.
> Potentionally the RNG isn't initialized at all and you actually
> have to wait for the kernel to get it's
On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > > Source:
On 2018-10-27 18:36:12 [+0200], Christoph Biedl wrote:
> +--- a/ipseckey.c
> b/ipseckey.c
> +@@ -111,8 +111,11 @@
> + default:
> + strcpy(gw, "??");
> + }
> ++#pragma GCC diagnostic push
> ++#pragma GCC diagnostic ignored "-Wformat-truncation"
> + snprintf(s, 1024, "(
On 2018-08-30 13:35:27 [+0200], David BERCOT wrote:
> With OpenSSL vv1.1.1~~pre9-1, I can't connect to my entreprise network (Wifi,
> PEAP\MSCHAPv2).
>
> The connection attempt arrives at the Radius server but, obviously, the
> exchange is "disturbed" and raises the following error:
> wlp60s0:
On 2018-10-27 17:18:22 [-0400], ant wrote:
> here is the message:
>
> =
> getmail version 5.6
> Copyright (C) 1998-2012 Charles Cazabon. Licensed under the GNU GPL version
> 2.
> SimplePOP3SSLRetriever:a...@anthive.com@mail.anthive.com:995:
> rc-03ant: socket error ([SSL:
On 2018-10-19 21:26:13 [+], Thorsten Glaser wrote:
> OndÅej Surý dixit:
>
> >Your initial bug report was inappropriate.
>
> No, it was not.
I think it was. I don't care much about the tone here others might. From
the technical point of view you used severity `grave' which is wrong
because
On 2018-10-26 16:13:35 [+0200], intrigeri wrote:
> Hi!
Hi,
> Given python3.5 was removed from testing, won't be shipped in Buster,
> and has no reverse dependencies left for release architectures (see
> #883630, situation today is almost entirely the same as since
> 3 months), I don't see any
On 2018-10-20 10:42:06 [+0100], Adam D. Barratt wrote:
> On Wed, 2018-10-17 at 00:26 +0200, Sebastian Andrzej Siewior wrote:
> > clamav upstream published a new version which contains security
> > relevant bug fixes, one of them has CVE-2018-15378 assigned.
>
> Is the expect
On 2018-10-17 21:21:29 [+0200], Kurt Roeckx wrote:
> > - src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1
>
> I'm not sure if this is actually still a problem, there have been
> fixes on the python and openssl side for this. reproducible builds
> shows it as having problems trying to
Package: ftp.debian.org
Severity: normal
Hi,
The source package txtorcon no longer builds the binary package
python-txtorcon. The binary package is still in archive and was not
auto-decrufted. Removing the package breakds two other packages:
|bigeasy@coccia:~$ dak rm -Rnb python-txtorcon
|Will
Package: foolscap
Version: 0.13.1-1
Severity: serious
txtorcon does not build the Python2 variant (python-txtorcon) since its
last upload, only the python3 one (python3-txtorcon) remains.
As of now the package can't be built due to missing packages.
Sebastian
--- clamav-0.100.1+dfsg/debian/changelog 2018-07-21 13:13:59.00000
+0200
+++ clamav-0.100.2+dfsg/debian/changelog2018-10-12 23:44:44.0
+0200
@@ -1,3 +1,14 @@
+clamav (0.100.2+dfsg-0+deb9u1) stretch; urgency=medium
+
+ * Import new upstream
+- Bump symbol version d
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
Hi,
kannel-sqlbox was uploaded slightly after kannel 1.4.5-2. On most
architectures, kannel-sqlbox was built against newer kannel-dev
resulting in a dependency on libssl1.1. On a few
On 2018-08-05 13:18:26 [+0200], To Marc Dequènes wrote:
> I didn't manage to reproduce it yet. My plan was to to gather enough
this is still the case.
> informations to reproduce it and forward it upstream.
> Is there anything wrong / different with my setup compared to your?
> Maybe different
if self.key_file:
> 127 context.load_cert_chain(certfile=self.cert_file,
> keyfile=self.key_file)
Thank you. Attached the fixed version and forwarded upstream.
Sebastian
>From f5e7f6c98b46ff622f60a4661ffc9ce07216d109 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date
:726)
It looks like missing SNI support.
Could you please try if the patch attached works? It is completly
untested it just looks like it might work…
Sebastian
>From 978e87c8f0dfb93c26814b5e5806d2f2332db164 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior
Date: Sat, 29 Sep 2018 21:4
On 2018-08-27 22:52:06 [+0200], Sandro Knauß wrote:
> Source: qtbase-opensource-src, kimap
> Version: kimap/18.07.90-1
> Control: block 907015 by -1
>
> When I built my KDE PIM packages locally I built against openssl 1.1.0h-4 and
> I had no issues running the KIMAP tests.
> With openssl
On 2018-09-05 10:30:23 [-0400], Antoine Beaupré wrote:
> Control: block 907807 by 907015
>
> On 2018-09-05 15:53:46, Vincent Bernat wrote:
> > ❦ 5 septembre 2018 09:30 -0400, Antoine Beaupré :
> >
> >> So I've forwarded the bug upstream to see if we can get a hint there. I
> >> originally
On 2018-08-29 11:38:54 [-0600], dann frazier wrote:
> > > error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
> > >
> > > I found that backporting bip 0.9.0~rc3-1 to jessie worked. I further found
> > > that just cherry-picking the following commit back to bip 0.8.9 seems to
> > >
control: unblock 907015 by 907788
On 2018-09-02 09:59:11 [+0200], VA wrote:
> Since openssl upgrade to 1.1.1~~pre9-1, curl is not able anymore to do
> requests to some sites. For example:
>
> % curl https://www.credit-cooperatif.coop/
> curl: (35) error:141A318A:SSL
On 2018-09-02 10:20:13 [+0200], Paul Gevers wrote:
> Dear ruby2.5 maintainers,
>
> Recently openssl was updated to upstream version 1.1.1. There have been
> multiple changes to increase security. As a result, some packages
> started to time out during autopkgtest and/or building of the package.
>
On 2018-09-26 11:44:14 [+0100], Colin Watson wrote:
>
> Upstream committed the necessary changes to switch to the 1.1 API
> earlier this month, so that should be in OpenSSH 7.9. There's usually a
> release every few months, so I think we should be OK to just wait for
> that now.
okay, thanks
On 2018-07-31 21:40:25 [+0200], To Emilio Pozuelo Monfort wrote:
> On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> > We never break packages in testing (unless it's a critical situation, and
> > this
> > obviously isn't). Also the cruft package in unstable doesn't hurt much, so
>
On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > Source: kopete
> > Source-Version: 4:18.04.1-1
> >
> > We believe that the bug you reported is fixed in the latest version of
> > kopete, which is due to be installed in the
On 2018-07-28 07:56:58 [+0200], Kurt Roeckx wrote:
> Hi,
Hi,
> Any update on this?
...
> There are very few packages in testing that still use OpenSSL
> 1.0.2, and it looks like openssh is the only reason to keep it
> around.
we are down to two users in testing with one of them fixed in
control: tags -1 patch
https://github.com/jcristau/imaplib2/commit/a7ce7da1d573849ac2e1d740d8f3238e0ad8d88c
Sebastian
On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote:
> Dmitry already implemented my short-term workaround:
> https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/
>
> When this has been built on all release architectures openssl can bump
> the
On 2018-09-11 12:57:17 [+0300], Adrian Bunk wrote:
> > I'm on buster and with the latest updates from yesterday came
> > qtbase-opensource-src 5.11.1+dfsg-7
> > and SSL started to fail in Qt5 programs. This was reported in bug 907774 ~
> > 2 weeks ago.
> >
> > Basically libssl 1.1.1 (in
On 2018-08-23 09:07:31 [+0200], Paul Gevers wrote:
> 2) enable the openssl package to collect information which packages it
> breaks and which version of those package fix the issue. With that
> information the openssl package can add versioned Breaks
>
> We believe that the versioned Breaks are
+- Fix segfault ERR_clear_error (Closes: #903566)
+- Fix commandline option for CAengine (Closes: #907457)
+ * Abort the build if symbols are discovered which are not part of the
+symbols file.
+
+ -- Sebastian Andrzej Siewior Mon, 03 Sep 2018 23:59:02 +0200
+
openssl (1.1.0f-3+deb9
On 2018-07-27 23:56:53 [+0200], To Marc Dequènes wrote:
> On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > > I just tried loading Adam's configuration on another system to test the
> > > ScanOnAccess, copied a clamav test file in one of the protected directory
> > > and hit the problem.
On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> We never break packages in testing (unless it's a critical situation, and this
> obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
> can be left around for a while longer. What we want to do here is to get
On 2018-07-29 22:01:20 [+0100], Adam D. Barratt wrote:
>
> ClamAV is an AntiVirus toolkit for Unix.
>
> Upstream published version 0.100.1.
>
> This is a mostly a bug-fix release. The changes are not strictly
> required for operation, but users of the previous version in stretch
> may not be
On 2018-07-28 09:24:28 [+0100], Adam D. Barratt wrote:
> Was the intent that the package would be pushed via -updates?
Yes, please. If you need additinal information I can provide then on
Sunday evening.
> Regards,
>
> Adam
Sebastian
On 2018-07-25 22:03:46 [+0200], To Marc Dequènes wrote:
> > I just tried loading Adam's configuration on another system to test the
> > ScanOnAccess, copied a clamav test file in one of the protected directory
> > and hit the problem. After that the whole machine becomes totally
> > unresponsive
On 2018-07-25 12:14:17 [+0900], Marc Dequènes (duck) wrote:
> Quack,
>
> I did not try to switch on ScanOnAccess on my production system, but with my
> configuration, which is not that different, I do not have the problem.
>
> I just tried loading Adam's configuration on another system to test
On 2018-07-25 10:47:50 [+0200], Emilio Pozuelo Monfort wrote:
> > Any suggestions from the D-Science folks?
>
> Maybe send this to the scilab bug rather than the curl transition one?
I Cced the scilab folks. I was more interrested in the release team's
opinion if it is worth fixing those and get
On 2018-07-24 11:06:01 [+], Scott Kitterman wrote:
> On July 24, 2018 10:42:44 AM UTC, richard lucassen
> wrote:
> >http://tmp.xaq.nl/clamd.strace
…
> >plus a vanilla install of clamav-unofficial-sigs.
>
> That looks like a different issue. Does it still happen if you remove
>
On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote:
> Quack,
Hi,
> I just upgraded and cannot reproduce this problem. I'm not using the
> ScanOnAccess feature.
just to confirm: you can not reproduce the problem.
> Follows collected config info.
> \_o<
Sebastian
On 2018-07-23 18:26:04 [+0200], Richard Lucassen wrote:
> Same here (6 Postfix front-end servers), non-systemd, non-GUI system
> running Debian Stretch. Downgrading to 0.99 is a workaround.
> ScanOnAccess is set to false.
Is the kernel complaining about something like in the other report where
it
On 2018-07-22 20:10:08 [+0800], intrigeri wrote:
> Looking at the Journal, it looks very much like the clamav-freshclam
> service is started before the /usr/bin/freshclam AppArmor profile
> is loaded.
>
> I think this is potentially racy, which might be why the problem can't
> trivially be
On 2018-07-19 00:39:27 [+0200], To Emilio Pozuelo Monfort wrote:
> - scilab
> rebuilt everywhere except for i386. Plus
> #891351 [G| | ] [scilab] scilab segfaults at startup
> #875790 [S|⛺+| ] [src:scilab] scilab: depends on openjdk-8
> #884033 [S| |☣] [scilab] scilab segfaults
spack ],[yes],[$mspack_msg])
if test "x$XML_LIBS" = "x"; then
CL_MSG_STATUS([libxml2 ],[no],[])
else
CL_MSG_STATUS([libxml2 ],[yes, from $XML_HOME],[])
fi
CL_MSG_STATUS([yara],[$enable_yara],[$enable_yara])
+CL_MSG_STATUS([fts ],[yes],[$lfs
On 2018-07-20 17:16:40 [-0400], Mike Rotondo wrote:
>I expected an update to roll out that fixed the problem
Thank you for the informative bug report. If I put the pieces correctly
together then since the point release you have your apache2 server not
serving ALPN/h2 but only "normal"
g the behavior of
the wake functions.
Signed-off-by: John Ogness
Acked-by: Sebastian Andrzej Siewior
Reviewed-by: Kurt Kanzenbach
Signed-off-by: Kurt Kanzenbach
---
nptl/pthread_cond_timedwait.c | 4 +++-
nptl/pthread_cond_wait.c | 4 +++-
2 files changed, 6 insertions(+
On 2018-07-19 13:38:04 [-0700], Adam Lambert wrote:
> clamd (28514): Using fanotify permission checks may lead to deadlock;
> tainting kernel
> and shortly thereafter
This seems to become true.
> INFO: task clamd:28512 blocked for more than 120 seconds.
That is deadlock that happens.
> I
control: tags 901361 - moreinfo
control: reassign 901879 ftp.debian.org
control: retitle 901879 RM: wvdial -- unmaintained, dead upstream, depends on
wvdial
here I am one month later. Nobody tried to adopt wvdial or wvstreams
within the last month.
Please remove both from unstable.
Sebastian
On 2018-05-28 17:43:15 [+0200], Emilio Pozuelo Monfort wrote:
> Let's go with this. I'll schedule the binNMUs soon.
atm we have:
- netsurf (sid only)
#867694 [G| | ] [netsurf-fb] netsurf-fb: Completely unusable due to missing
dependencies, symlinks and documentation
#859230 [S| | ]
: #901430).
+
+ -- Sebastian Andrzej Siewior Thu, 19 Jul 2018 00:03:21 +0200
+
freeipa (4.6.3-1) unstable; urgency=medium
* New upstream release.
diff -Nru freeipa-4.6.3/debian/control freeipa-4.6.3/debian/control
--- freeipa-4.6.3/debian/control 2018-02-01 13:14:03.0 +0100
+++ freeipa
-depends (Closes: #896793).
+
+ -- Sebastian Andrzej Siewior Wed, 18 Jul 2018 23:52:45 +0200
+
openalpr (2.3.0-1) unstable; urgency=low
* Added plate detection mask and prewarp config changes via API
diff -Nru openalpr-2.3.0/debian/control openalpr-2.3.0/debian/control
--- openalpr-2.3.0/debian
: #869600).
+
+ -- Sebastian Andrzej Siewior Wed, 18 Jul 2018 23:25:47 +0200
+
netsurf (3.6-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru netsurf-3.6/debian/control netsurf-3.6/debian/control
--- netsurf-3.6/debian/control 2017-02-08 21:08:27.0 +0100
+++ netsurf-3.6
On 2018-07-11 14:25:46 [+0200], Bernd Zeimetz wrote:
> Hi,
Hi,
> This is fixed since one year in the openssl 1.1.0 stable branch.
so I do have a little side project where I try to bring the latest 1.1.0
stable release into Debian stable via p-u for reasons like this.
Do I understand this
On 2018-07-09 22:45:15 [+0200], Matija Nalis wrote:
> I got bitten by this too in jessie-updates (after wasting some time
> being *sure* local signature I was just creating at the time made
> clamd crash silently)...
wasn't there an assert which made clamd exit?
…
> Still wondering how much of
On 2018-07-10 04:05:58 [+0200], Philippe Metzger wrote:
> For now it seems that OpenSSL 1.1.0f-3+deb9u2 available in stretch/security
> force TLS 1.2 only in https when using Apache (whatever SSLProtocol
> Directive specify).
This is not true. Stretch has TLS1.0 and up enabled by default.
> Is
On 7 July 2018 04:24:20 CEST, Shawn Landden wrote:
>I would like it if there was a debug package for libssl1.1 so I could
>better profile transmission with perf.
What is wrong with dbgsym we currently provide?
Take a look at https://wiki.debian.org/AutomaticDebugPackages
on how to install them.
control: reopen -1
control: notfixed -1 8.11.2~dfsg-1
On 2018-05-17 18:10:35 [+], Jérémy Lal wrote:
> Source: nodejs
> Source-Version: 8.11.2~dfsg-1
…
>* Upstream openssl 1.1.1 wip patches (Closes: #898805)
> Also make sure tests still run with openssl 1.1.0
I rebuilt 8.11.2~dfsg-1
On 2018-07-05 23:52:31 [+0200], Bernhard Schmidt wrote:
> Hi Sebastian,
Hi Bernhard,
> I totally agree and I have already done this. I have filed a bug because
> I assume this will hit at least some people on the next Stretch point
> release hard. Not sure whether one can workaround this in
control: forwarded -1 https://bugzilla.clamav.net/show_bug.cgi?id=12077
On 2018-07-05 22:54:58 [+0200], Bernhard Schmidt wrote:
> On 04.07.2018 14:00, Sebastian Andrzej Siewior wrote:
>
> Hi Sebastian,
Hi Bernhard,
> Attached. Note that antidebug_antivm.yar is the one wit
On 2018-07-05 06:25:45 [+0100], Adam D. Barratt wrote:
> Please go ahead.
uploaded, thanks.
> Regards,
>
> Adam
Sebastian
g-0+deb9u2) stretch; urgency=medium
+
+ * Don't fail on recently removed config options (Closes: #902290).
+
+ -- Sebastian Andrzej Siewior Wed, 04 Jul 2018 23:14:43 +0200
+
clamav (0.100.0+dfsg-0+deb9u1) stretch; urgency=medium
[ Sebastian Andrzej Siewior ]
diff -Nru clamav-0.100.0+dfsg/debia
control: tags -1 patch
On 2018-07-04 14:06:54 [+0200], To Hans van Kranenburg wrote:
> On 2018-06-24 17:12:19 [+0200], Hans van Kranenburg wrote:
> > My mailserver logs now contain 'ERROR: Parse error at line 74: Unknown
> > option StatsHostID', and when that's removed, it reports the next option
On 2018-06-24 17:12:19 [+0200], Hans van Kranenburg wrote:
> My mailserver logs now contain 'ERROR: Parse error at line 74: Unknown
> option StatsHostID', and when that's removed, it reports the next option
> that is removed, 'StatsPEDisabled', and so on.
…
> Or, alternatively when throwing newer
On 2018-07-03 09:04:21 [+0200], Bernhard Schmidt wrote:
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror():
> /var/lib/clamav/antidebug_antivm.yar line 544 undefined identifier "pe"
> Jul 03 07:30:24 mail clamd[21927]: LibClamAV Error: yyerror():
>
On 2018-06-13 08:19:32 [+0200], To Axel Beckert wrote:
> I asked upstream what they thing about ignoring these errors because the
> perl script does so. On the other hand what about cleaning up these
> dangling symlinks?
ca-certificate maintainers: what do we do here?
[ ] we intend to figure out
Package: wnpp
Severity: normal
I intend to orphan the wvdial package. The package has been removed from
testing because wvstreams is RC-buggy due to the its dependency on
libssl1.0.2. The whole story is in #901361 [0].
The persons that intends to adopt wvdial should also look after
wvstreams.
Marvin, do you have any plans here? Upstream made it clear that they
won't support openssl 1.1.0+ and I doubt that an embedded copy of the
ssl library will work here (not saying it won't, it is not my
decision).
Sebastian
On 2018-06-13 00:10:57 [+0200], Axel Beckert wrote:
> Hi Sebastian,
Hi Axel,
> Sebastian Andrzej Siewior wrote:
> > > I don't think so unless a future upload of OpenSSL to unstable fixes
> > > this. The recent one to unstable didn't.
> >
> > forwarded https
On 2018-06-12 22:29:42 [+0200], Axel Beckert wrote:
> Shall I try the version from Experimental, too?
no.
> > (Should some Breaks be added, Depends made stricter?)
>
> I don't think so unless a future upload of OpenSSL to unstable fixes
> this. The recent one to unstable didn't.
forwarded
Package: ftp.debian.org
wvstreams is rc-buggy due to its libssl1.0.2 requirement, QA maintained.
I asked about its status on d-qa-packages@l.d.o [0] and later on
d-devel@l.d.o [1].
wvstreams is dead upstream, last github commit is from 2011.
Its only reverse dependency is wvdial (Debian
On 2017-03-01 12:53:23 [+1300], Olly Betts wrote:
> Upstream addressed this by avoiding linking libxapianbackend.so to
> openssl (apparently it doesn't use it anyway):
>
> https://github.com/FabriceColin/pinot/commit/3a40d5abe159a106f3aabaedf1a199020946b3b5
pinot has currently two RC bugs and
On 2018-04-22 16:55:21 [+0200], Axel Beckert wrote:
> Hi Michael,
Hi,
> Michael Shuler wrote:
> > Thanks for the details. #895473 reported a similar error on locally
> > installed CA certificates, which I think may be related.
>
> That other bug report indeed looks similar albeit not identical.
Source: ruby-eventmachine
Version: 1.0.7-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: ruby-openssl
Version: 2.0.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: python-glanceclient
Version: 1:2.9.1-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl
Source: python3.5
Version: 3.5.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: puma
Version: 3.11.3-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in
Source: python2.7
Version: 2.7.15-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: pion
Version: 5.0.7+dfsg-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: openvswitch
Version:
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in
Source: nsca-ng
Version: 1.5-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in
Source: nova
Version: 2:17.0.0-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently
Source: nodejs
Version: 8.11.1~dfsg-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: myproxy
Version: 6.1.28-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently
Source: globus-gssapi-gsi
Version: 13.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: globus-gram-job-manager
Version: 14.36-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl
Source: globus-gass-copy
Version: 9.28-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: foolscap
Version: 0.13.1-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
On 2018-05-12 05:38:05 [+], Sander Jonkers wrote:
> Second command (goed wrong):
> # openssl req -new -x509 -key example.com.key -out example.com.cert -days
> 3650 -subj /CN=example.com
> Can't load /root/.rnd into RNG
> 140283178746304:error:2406F079:random number
Source: m2crypto
Version: 0.27.0-5
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: globus-ftp-client
Version: 8.36-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
Source: u1db
Version: 13.10-6.2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently
On 2018-04-18 00:16:41 [+0200], To sub...@bugs.debian.org wrote:
> There is openssl 1.1.1-pre4 in experimental right now and
> libnet-ssleay-perl fails the testsuite with it.
The complete buildlog
Source: bind9
Version: 1:9.11.3+dfsg-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1
The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version
On 2018-05-02 18:34:35 [+0200], Kurt Roeckx wrote:
> On Wed, May 02, 2018 at 05:19:20PM +0100, Simon McVittie wrote:
> > * https://github.com/openssl/openssl/pull/5967
> >
> > """
> > Commit d316cdc introduced some extra
> > checks into the session-cache update procedure, intended to
/AppArmor for information and
documentation on modifying apparmor profiles.
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,26 @@
+clamav (0.100.0+dfsg-0+deb8u1) jessie; urgency=medium
+
+ [ Sebastian Andrzej Siewior ]
+ * New upstream
On 2018-04-18 16:14:37 [+0200], Kurt Roeckx wrote:
> I can't see a reason why TLS 1.3 would be different in this regard,
> I expect the same behaviour for all SSL/TLS version. Anyway, it
> could just have been some code refactor that "fixed" it so that it
> generates the error now. Or maybe the
601 - 700 of 1864 matches
Mail list logo
