On 2023-06-12 08:39:53 [+0300], Martin-Éric Racine wrote:
> Syslog already suggests what the fix should be:
>
> $ grep Clamonacc /var/log/syslog
> 2023-06-12T08:33:40.562184+03:00 p8h61 clamonacc[248359]: ERROR:
> Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname,
> or
On 2023-06-26 18:10:57 [+0100], Jonathan Wiltshire wrote:
> Control: tag -1 moreinfo
>
> You're both going to have to help me a) understand what is the user-facing
> problem you're solving which is necessary to fix in stable and b) whether
> you're both agreed on how to fix it.
a) The bpo of
control: retitle -1 unblock: openssl/3.0.9-1
On 2023-05-30 22:16:53 [+0200], To sub...@bugs.debian.org wrote:
>
> Please unblock package openssl.
>
> The 3.0.9 release contains security and non-security related fixes for
> the package. There are five new CVEs in total that has been addressed.
>
On 2023-05-09 22:58:43 [+0200], Samuel Thibault wrote:
> My patch is not a nop. Previously to Lasse's commit, the
> --enable-assembler=x86_64 option would make no difference from
> --enable-assembler=no. With Lasse's commit, --enable-assembler=x86_64
> is now *refused* by ./configure. And thus
On 2023-05-06 15:49:33 [+0200], Samuel Thibault wrote:
> debian/rules is passing --enable-assembler=x86_64 to configure, but that
> case was removed, see ChangeLog:
>
> commit ac10b1b3622e70881595586edfb8a3ebdcd76bb6
> Author: Lasse Collin
> Date: 2022-11-14 17:58:07 +0200
>
> Build: Omit
control: retitle -1 openssh: Relax version check with OpenSSL 3.0+
control: tags -1 fixed-upstream
control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3548
It has been fixed upstream in commit
b7afd8a4ecaca ("Handle OpenSSL >=3 ABI compatibility.")
Sebastian
u use Network-Manager.
I retried it and it appears to be openssh. It might be the part with the
X on startup starts the ssh agent and this fails since the ssh command
itself aborts due to the version check.
I kept the severity as reported but it only affects openssl in
experimental.
Sebastian
From: Sebastian
On 2023-04-30 18:43:18 [+0200], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,
> > - the backport package of manpages-de and manpages-fr provides a
> > man page for xz. These files conflict with the one provided by
> > xz-utils package. The bpo package and xz-utils in Bookworm have
Package: mutt
Version: 2.2.9-1
Severity: important
control: tags -1 patch upstream fixed-upstream
control: forwarded -1
https://gitlab.com/muttmua/mutt/-/commit/5df86199463b5cf893fb6a37457fa02804d3b02a.patch
>From https://gitlab.com/muttmua/mutt/-/issues/400
| Currently, mutt message-id
On 25 February 2023 16:20:45 UTC, Scott Kitterman wrote:
>True.
>
>I'm not a C programmer, so I may be unduly concerned about the maintenance
>load. I'll defer to your judgement.
I'm going to throw this on my machine to get more testing - more than just the
test suite.
What about going
On 25 February 2023 14:57:28 UTC, Scott Kitterman wrote:
>Generally favorably, but I'd rather wait for upstream to agree on it,
>otherwise it may be a patch we have to maintain forever.
Now we maintain the tfm bits.
>What's their reaction to the change?
No reply so far. The first few patches
On 2023-02-24 21:00:43 [+], Scott Kitterman wrote:
> I don't know of anything. I'd go ahead and upload the fix.
how do you feel about replacing libtfm with openssl?
> Scott K
Sebastian
On 2023-02-24 12:44:49 [-0800], Nye Liu wrote:
> On Fri, Feb 24, 2023 at 09:39:03PM +0100, Sebastian Andrzej Siewior wrote:
> > Can you re-install libtfm1 and ensure that both point to that lib?
>
> libtfm1 0.13-4.1 fixed the problem. Should probably be version bumped in the
&
On 2023-02-24 12:21:48 [-0800], Nye Liu wrote:
> Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: in cli_cvdload()
> Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: MD5(.tar.gz) =
> f7eaac9ce4a83cc4c2526fe8f7d669db
> Feb 24 12:19:44 ln clamd[1537504]: LibClamAV debug: cli_versig: Decoded
On 2023-02-24 11:22:12 [-0800], Nye Liu wrote:
> Tried mirroring working cvds from another machine
>
> $ md5sum *
> 09c62fbb8d2de9cfeca516b3927347ba bytecode.cvd
> 7294b378c7bd3bf86314365d96aea3e4 daily.cvd
> a7bd2fc1eafcb260e76769a5821cb204 freshclam.dat
> 3a42e5027c90fba0e54d2abdaa9e86b4
+LTS
On 2023-02-20 12:22:48 [+0200], Andries Malan wrote:
> Hi There
Hi,
> Would you be so kind as to provide an ETA for the above mentioned bug that
> was reported.
> This would be greatly appreciated.
I Cced the LTS team because Buster is LTS territory.
> Regards
Sebastian
On 2023-02-18 08:58:57 [+], Laura Smith wrote:
> Could you confirm when the Debian Bullseye updates are due to be uploaded ?
https://bugs.debian.org/1031536
> Thanks !
Sebastian
ig
AC_CONFIG_AUX_DIR([config])
diff -Nru clamav-0.103.7+dfsg/debian/changelog clamav-0.103.8+dfsg/debian/changelog
--- clamav-0.103.7+dfsg/debian/changelog 2022-08-21 21:28:52.0 +0200
+++ clamav-0.103.8+dfsg/debian/changelog 2023-02-17 21:43:57.0 +0100
@@ -1,3 +1,11 @@
+clamav (0
Source: puma
Version: 5.6.5-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
Your package has an autopkgtest, great. However, it fails from time to
time.
From
On 2023-02-10 20:22:54 [+], Thorsten Glaser wrote:
> Sebastian Andrzej Siewior dixit:
>
> >Good. So unless Thorsten disagrees this is done ;)
>
> Please also test the upgrade with 4.16.0-1~bpo11+1 installed
> on bullseye instead of 4.17.0-2~bpo11+1 (since that is a
On 2023-02-10 20:43:01 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,
> From the manpages-l10n side everything is in place, I would then also
> properly close #1028233. (Uploads to bpo do not manipulate the BTS).
Good. So unless Thorsten disagrees this is done ;)
> Greetings
>
>
On 2023-02-01 17:59:57 [+], Thorsten Glaser wrote:
> > xz-utils (5.4.1-0.1) unstable; urgency=medium
> > .
> > * Non-maintainer upload.
> > * Update pt_BR translations.
> > * Add lintian overrides and an override for blhc.
>
> This is missing the updated Breaks+Replaces for
On 2023-02-03 10:43:43 [+0800], zhangdandan wrote:
> Dear maintainer(s),
> The configuration of Loongarch64 should be modified in Openssl.
> Please consider the suggestion of Han Gao. I have tested the patch.
So it has been tested, thank you.
There will be an upload on TUE evenning of 3.0.8
On 31 January 2023 08:00:23 UTC, Thorsten Glaser wrote:
>Sebastian Andrzej Siewior dixit:
>
>>Then I will update the versions as suggested. My understanding was the
>>problem persists because the bpo version was not yet updated. The
>>version in sid did not ship the man-p
On 2023-01-30 21:57:28 [+], Thorsten Glaser wrote:
> Sebastian Andrzej Siewior dixit:
>
> >Okay. So I do nothing and just wait for the bpo package to appear which
> >will then solve the problem?
>
> No, you must fix the problem in xz-utils in bookworm/sid as well.
On 2023-01-30 21:51:11 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,
> On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote:
> > > reopen 1028375
> > > found
On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote:
> reopen 1028375
> found 1028375 5.4.1-0.0
> thanks
>
> Patrice Duroux dixit:
>
> >Was this supposed to be closed? Or will it be with another manpages-fr bpo?
>
> 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1)
> so the upload did
control: forwarded -1 https://translationproject.org/domain/xz.html
On 2023-01-21 16:36:30 [+0100], Helge Kreutzmann wrote:
> Please kindly include the attached da.po and forward it to upstream so
> that it is included there in future versions as well.
upstream (xz) does not accept any
On 2023-01-21 00:05:53 [+0800], Han Gao wrote:
> Loongarch64 is little endian. So [1] should be removed.
Are you sure? I applied exactly what I received in #1024414. Please test
the patches that you send.
> [1]:
>
Package: devscripts
Version: 2.22.2
Severity: wishlist
uscan can created a repacked file based on d/copyright and I *think*
this is handled by devscripts. It invokes `xz' for compression without
the -T flag. Passing the -T argument with either 0 or 1 as the number of
CPUs has the following
On 2023-01-19 12:02:52 [-0800], Ryan Tandy wrote:
> Hello Jonathan and Sebastian.
Hi Ryan,
> In any case I believe the use of Recommends is Policy-compliant since there
> are myriad ways to specify the trusted CAs and the default ldap.conf setting
> is only for convenience.
It sounds reasonable.
control: reassign -1 ldap-utils 2.4.57+dfsg-3
On 2023-01-04 13:50:53 [+], Jonathan Rietveld wrote:
> We've since found out that installing libldap-common resolves our
> issue, as others
> (https://github.com/wheelybird/ldap-user-manager/issues/172 and
>
On 2023-01-11 21:01:11 [+0100], To Helge Kreutzmann wrote:
> > For your update you should use as version "<< 4.1.0-1".
> > (and remember to put it in for both manpages-de and manpages-fr)
>
> Okay, will do.
Just to double check: This is what I did:
On 2023-01-11 21:53:14 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hello Helge,
> Well, this is not correct. See, e.g.,
> https://packages.debian.org/bullseye-backports/all/manpages-de/filelist
>
> The man pages are there.
yes, in backports. Not in the "regular" package.
> Of course,
On 2023-01-10 09:36:04 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,
> On Mon, Jan 09, 2023 at 09:38:31PM +0100, Sebastian Andrzej Siewior wrote:
> Sorry, I was really tired yesterday evening and just wanted to send a
> short "ack".
no worries. Just wa
On 2023-01-09 21:13:16 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,
just to correct your previous email, the bug report was/is from Raphaël
Halimi not me. I just pinged you.
> > Interresing. manpages-fr and manpages-de from manpages-l10n in bookworm
> > does not ship
On 2023-01-08 18:32:26 [+0100], Raphaël Halimi wrote:
> Today I tried to upgrade a Bullseye laptop to Bookworm.
>
> The upgrade crashed with xz-utils trying to overwrite
> /usr/share/man/fr/man1/xz.1.gz which belonged to manpages-fr from backports
> (4.16.0-3~bpo11+1).
>
> After running dpkg
Package: trace-cmd
Version: 3.1.4-1
Severity: wishlist
A new version of trace-cmd, 3.1.5, is available. Please package it for
Bookworm.
Sebastian
On 2023-01-03 20:21:57 [+], Jonathan wrote:
> Package: openssl
>* What led up to the situation?
>
> After trying to update to bullseye, connecting to our LDAP server no longer
> works, both with pam_ldap package as well as using ldapsearch from ldap-utils.
What happens with if you add
On 2022-12-31 01:09:46 [-0500], Scott Kitterman wrote:
> I looked at it some and the testfiles appear to be gone. Let's drop the
> binary
> and move on.
I references them from the build-directory. So we have some of them. I
don't know if new files are there (in the build directory) but the
On 2020-04-09 19:43:34 [+0800], Paul Wise wrote:
> On Thu, 9 Apr 2020 11:45:49 +0200 Sebastian Andrzej Siewior wrote:
>
> > Can this be closed?
>
> Since the patch and feature hasn't been merged, I don't think so.
What about now given that #956452 has been closed?
Sebastian
On 2022-12-31 01:09:46 [-0500], Scott Kitterman wrote:
> I discovered that the experimental (and upstream-experimental) branches still
> have the crates that are now excluded when the tarball is created. I made a
> new branch called upstream-experimental-fixup and pushed it. You ought to be
>
On 2022-12-30 16:22:21 [-0500], Scott Kitterman wrote:
> Great. I finished the changes for the embedded crates (it's not perfect
> machine readable copyright format, but it's close and I think it will do for
> the moment) and pushed the change. It should be a fast forward for you when
> you
On 2022-12-29 00:37:20 [-0500], Scott Kitterman wrote:
> I've pushed additional d/copyright changes to the experimental branch. With
> those changes, uscan should produce a DFSG free tarball. Because I ripped
> out
> all the Windows specific stuff, the Rust crates don't compile. I don't know
On 2022-12-26 10:50:44 [+0100], Joerg Dorchain wrote:
> the latest update to version 0.103.7+dfsg-1+b2 gives for me
> ERROR: Can't verify database integrity
> for clamav-daemon and clamav-freshclam
>
> Downgrading to libclamav9 0.103.7+dfsg-1+b1 as a workaround
> helps.
Just to be clear: You
On 2022-12-22 18:31:37 [-0500], Scott Kitterman wrote:
> I think we should focus on getting clamav up to 1.0.0 before the freeze and
> deal with the unrar bits later (should be easy enough to get a freeze
> exception for if we need it).
>
> If you think tha'ts reasonable, I'll manually make the
On 2022-12-12 22:45:57 [-0500], Scott Kitterman wrote:
>
> That doesn't sound too bad. I'll see if I can find some time to work on the
> split, but probably not until Wednesday or Friday.
So I managed to tell cmake to use the tfm library instead of the bundled
code and the testsuite fails now
Package: libtracefs
Version: 1.5.0-1
Severity: wishlist
Please update libtracefs to v1.6+. The later trace-cmd depends on 1.6+
Sebastian
On 2022-12-07 12:51:30 [-0500], Scott Kitterman wrote:
> OK. I'm back to having some time for Debian again, so let me know how I can
> help.
I pushed something to the experimental branch. It ain't much…
This updates the build dependencies and you still need download the
upstream .tar.gz
On 2022-10-30 14:44:16 [+], Scott Kitterman wrote:
> Looks like we'll also need to patch tomsfastmath, such upstream parched their
> embedded copy:
>
> https://github.com/Cisco-Talos/clamav/commit/17e52a09a91d8f6535014873ab6cb99c827b5e20
that needs we need to do mini transition for libtfm1
On 2022-11-21 21:39:21 [+0100], John Paul Adrian Glaubitz wrote:
> Hi!
Hi,
> On 11/21/22 00:07, John Paul Adrian Glaubitz wrote:
> > This issue has shown in other packages such as glibc on ia64 [1]:
> >
> > /usr/bin/ld:
> > /<>/build-tree/ia64-libc/dlfcn/bug-atexit3-lib.so: version
> > node
On 2022-10-23 15:12:35 [+0200], Lucas Nussbaum wrote:
> Relevant part (hopefully):
> > debian/rules build
> > dh build --parallel
> > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> >dh_update_autotools_config -O--parallel
> >dh_auto_configure -O--parallel
>
On 2022-09-29 20:03:56 [+0200], Richard B. Kreckel wrote:
> On 9/27/22 08:15, Sebastian Andrzej Siewior wrote:
> > It is not part of any standard.
>
> It could hardly be less standardized. See ISO/IEC 10118-3:2018.
That is not what I meant.
Wahat I meant that it is par
On 2022-09-26 00:10:27 [+0200], Richard B. Kreckel wrote:
> W.r.t. RIPEMD160, this seems to be a mistake:
> https://github.com/openssl/openssl/issues/16994
> Also, Fedora seems to have worked around this.
The issue is not closed by OpenSSL upstream so there is nothing that I
can backport. I don't
On 2022-09-25 22:59:27 [+0200], Richard B. Kreckel wrote:
> On 9/25/22 21:14, Sebastian Andrzej Siewior wrote:
> > See the man page for OSSL_PROVIDER-legacy.
>
> Having to add a the extra option -provider legacy breaks otherwise flawless
> existing software.
This happens
On 23 September 2022 21:18:26 UTC, "Jérémy Lal" wrote:
>I'll upload nodejs 18.9.1 this week-end, along with a/your fix for that
>issue.
Thank you.
>
>Jérémy
--
Sebastian
control: found -1 odejs/18.7.0+dfsg-5
On 2022-09-23 22:55:23 [+0200], Jérémy Lal wrote:
> Thanks, I'm already aware of the need to run nodejs testsuite using
> their own specific openssl.cnf.
> It seems you are reporting a bug against a version of nodejs that has never
> made it
> to debian. Did
onfig
file.
A patch for the latter has been attached.
Sebastian
From: Sebastian Andrzej Siewior
Date: Fri, 23 Sep 2022 22:39:50 +0200
Subject: [PATCH] Add a CipherString for nodejs
If the default security level is overwritten at build time of openssl
then it is needed to lower it again for nodej
Package: openssl
Version: 3.0.5-3
Severity: serious
control: forwarded -1 https://github.com/openssl/openssl/issues/19243
After touching test/default.cnf in the last upload, the
90-test_threads.t test fails randomly on the last step
(test_lib_ctx_load_config()). Sometimes
"malloc():
On 2022-09-18 21:06:59 [+0200], Kurt Roeckx wrote:
> I'm not sure that having the legacy provider automatically enabled by
> default when it's installed is a good idea. That means once it's
> installed, all applications have it by default. I think it needs to be
> enabled per application.
The
On 2020-07-16 08:46:43 [+0200], Kurt Roeckx wrote:
> On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote:
> >
> > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
>
> That would actually make sense.
>
> We could use the include thing to ship a config file
On 2022-09-13 18:30:05 [+0200], Kurt Roeckx wrote:
> > > 3) provide a symlink from /usr/lib/ssl/cert.pem to
> > >/etc/ssl/certs/ca-certificates.crt
> >
> > Kurt, I tend to provide this symlink. Any objections?
> > I'm kind of confused that it works for others, like curl. But I don't
> > see
On 2016-01-04 23:50:10 [+0100], Jan Dittberner wrote:
> I don't know whether this will have negative side effects but from my point
> of view it would be nice if the openssl package would do one of the
> following to properly solve this issue:
>
> 1) properly load certificates from /etc/ssl/certs
On 2022-09-11 07:25:47 [-0400], Jeremy Bicha wrote:
> Attached. Or you can use the 2 Salsa merge proposals.
I prefer the workflow where it is attached to the bug. This makes things
easier for me, especially while traveling.
Fell free to reschedule it to 0-day/now.
Have they been forwarded
On 8 September 2022 11:44:16 UTC, Jeremy Bicha
wrote:
>To allow clamtk-gnome to continue working after the Nautilus 43
>transition which will begin soon, I am uploading an NMU with a delay
>of 5 days to fix this bug. Please let me know if I should speed up or
>slow down this upload.
>
>The NMU
On 2022-09-02 17:02:38 [+0100], Adam D. Barratt wrote:
> Please go ahead, bearing in mind that the window for getting updates
> into 11.5 (and thus bullseye-updates prior to 11.5 being released)
> closes over this weekend.
just uploaded.
> Given that 11.5 is scheduled for a week tomorrow, would
Package: ftp.debian.org
X-Debbugs-Cc: sebast...@breakpoint.cc
Severity: normal
havp is no longer work as of linux-image-* v5.15. This is not a Debian
thing but actually the relevant code has been removed from the linux
kernel. The whole explanation is in
https://bugs.debian.org/1017637
909aed8
-7135300
+276875cec2e8a64a834e0c5e9f988aebe0d3ab25
+276875cec2e8a64a834e0c5e9f988aebe0d3ab25
+d1ea680af611ee417616ec3d8615a0e67a495795
+d1ea680af611ee417616ec3d8615a0e67a495795
+clamav_0.103.7+dfsg.orig.tar.xz
+f0708e3df3a432def23c384d28fb3a4628efcfd5
+7136624
diff --git a/debian/changelog b
af6e140ea150e0f219c86594f3bc04cb
+d1ea680af611ee417616ec3d8615a0e67a495795
+d1ea680af611ee417616ec3d8615a0e67a495795
+clamav_0.103.7+dfsg.orig.tar.xz
+f0708e3df3a432def23c384d28fb3a4628efcfd5
+7136624
diff --git a/debian/changelog b/debian/changelog
index c540f6f..5210a94 100644
--- a/debian/changelog
Source: havp
Version: 0.93-2
Severity: grave
While testing havp before uploading I noticed that starting havp ends
quickly with:
| Starting HAVP Version: 0.93
| Filesystem not supporting mandatory locks!
| On Linux, you need to mount filesystem with "-o mand"
The so called "mandatory locks" have
On 2022-08-02 20:18:32 [+0200], Jérémy Lal wrote:
> Indeed, something has changed somewhere else.
I've been looking at this because I assumed that something may be
different in the init path on mips vs everywhere else leading to a
similar kind of an error like the last time where the error
Package: openssl
Version: 3.0.5-1
Severity: serious
Control: forward -1 https://github.com/openssl/openssl/issues/18912
Control: affects -1 libnet-dns-sec-perl
It appears the EC code is broken for ed25519/ed448 on s390x.
Sebastian
On 2022-07-07 19:17:43 [+0300], Martin-Éric Racine wrote:
> Since the above bug report was filed, upstream has moved up to
> 0.105.0, while Debian is still at 0.103.6, so I was wondering what is
> going on?
The testing got a little bit easier since I had the same version
everywhere (old-stable/
control: notfound -1 1.1.1f-1ubuntu2.12
control: found -1 3.0.4-2
On 2022-07-21 12:25:51 [+0200], Alexey Brodkin wrote:
> Package: openssl
> Version: 1.1.1f-1ubuntu2.12
Please use Debian's verions, not Ubunut's.
This will only be addressed in unstable as it does not affect
stable/oldstable in
On 2020-07-03 11:37:39 [+0200], Michael Ott wrote:
> Dear Maintainer,
>
> After update openssl gsconnect does not longer work
>
> I already create a bug report on gsconnect
> https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/886#
>
> ~# cat /var/log/syslog | grep gsconnect
>
On 2021-10-26 12:21:20 [+0200], Vincent Lefevre wrote:
> On 2021-10-26 12:00:34 +0200, Dylan Aïssi wrote:
> > Wireplumber needs the libspa-0.2-bluetooth package to support
> > bluetooth. I guess it was missing from your system.
> > libspa-0.2-bluetooth is only a plugin, wireplumber can work
On 2022-05-20 19:16:06 [+0200], Bernhard Schmidt wrote:
> On 19/05/22 01:35 PM, Hopea Jonne wrote:
>
> > Uninstalling libssl-dev helped, for some reason libssl-dev also ships with
> > a
> > libssl.so binary which may or may not be of same version as other ones.
>
> I don't think this is the
On 2022-06-24 13:07:59 [+0200], Sébastien Noel wrote:
> Hi,
Hi,
> I had a similar crash with the same error message with openvpn.
> Downgrading libssl3 to version 3.0.3-8 did fix the issue.
>
> It seems to be related to this upstream bug:
> https://github.com/openssl/openssl/issues/18625
My
On 2022-06-20 19:10:27 [+0200], To Arthur Marsh wrote:
> I have here
>telnet-ssl 0.17.41+0.2-3.3+b1
>telnetd-ssl 0.17.41+0.2-3.3+b1
>libssl3 3.0.3-8
>openssl 3.0.3-8
adding
ckermit305~alpha07-1+b1
and then:
| ~$ kermit
| C-Kermit 9.0.305 OPEN SOURCE: Alpha.07,
On 2022-06-16 11:33:13 [+0930], Arthur Marsh wrote:
>* What led up to the situation?
>
> I also found that telnet-ssl and ckermit could not connect to telnetd-ssl
> if openssl 3.0.3-8 was installed.
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
>
On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,
> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.
I confirmed on eller that nodejs 16.15.0+dfsg-1 builds with openssl
3.0.3-7. I was about to give-it-back but then
control: forwarded -1 https://github.com/openssl/openssl/issues/18535
On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,
> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.
Okay. So if you do
On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,
> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.
I added RAND_status() as the first instruction in Start() (src/node.cc)
before InitializeOncePerProcess(). With
On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi,
> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.
before I forget:
on amd64 the entry point to init is:
| #0 OPENSSL_init_crypto (opts=opts@entry=64,
On 2022-06-08 20:07:48 [+0200], Jérémy Lal wrote:
> Hi Sebastian,
Hi Jérémy,
> Any hint or idea about this ? Even wild ideas that I could try,
> before I have to remove the files from mips.
for some reason ossl_err_load_crypto_strings() is not invoked on mipsel
but is invoked on amd64. Therefore
On 2022-06-09 23:18:07 [+0930], Arthur Marsh wrote:
…
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> Upgrading openssl, libssl3 to 3.0.3-7 from 3.0.3-6 on host system prevented
> ckermit 305~alpha07-1+b1 on client
On 2022-06-06 21:22:41 [+0200], MERLIN Philippe wrote:
> The non-functioning of SSL in version 3 is still relevant. Another example of
> its failure is given by a screenshot in p.J. this is a KDE bug report
> regarding Kdeconnect it says in French "impossible to contact bug.kde.org SSL
>
On 2022-06-08 22:13:09 [+0200], Sebastian Ramacher wrote:
> That would be much appreciated, thanks!
Did so, sorry for the delay. I aimed for Monday but…
> Cheers
Sebastian
On 2022-06-07 08:23:40 [+0200], Vincent Bernat wrote:
> Willy Tarreau already asked the team for QuicTLS packaging without an
> answer:
>
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
there was an answer:
On 5 June 2022 19:03:17 UTC, Kurt Roeckx wrote:
>The suggestion was to make an openssl.cnf that's compatible with 1.1.1,
>and so remove or comment out everything related to providers.
>
Ah okay. In that case let me so that tomorrow and close that rc bug with this
change.
>
>Kurt
>
--
On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote:
> Hi Sebastian
Hi Sebastian,
> > Otherwise I'd fear that the only other options are openssl breaking
> > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific
> > name. Given the high number reverse dependencies involved in
On 2022-05-31 23:47:15 [+0200], Jérémy Lal wrote:
> Le jeu. 26 mai 2022 à 09:01, Sebastian Andrzej Siewior <
> sebast...@breakpoint.cc> a écrit :
>
> Shout out... I've tried some things but it still fails.
> I think there's some bug or option activated on mipsel,
> th
On 2022-05-26 18:26:57 [+0200], Sebastian Ramacher wrote:
> Hi Sebastian
Hi,
> We're now at the following blockers for openssl's migration:
…
> Bugs for the autopkgtest regressions have been filed and some are
> already fixed in unstable. So I'll add hints to ignore those
> regressions.
good.
>
On 2022-05-26 13:49:13 [+0200], Jérémy Lal wrote:
> Thanks for the feedback.
np.
> Indeed, the latest nodejs version (18.x) embeds an updated openssl.cnf,
> which is exactly the one
> of the openssl debian package, without the [ssl_sect] part at the end.
>
> Why this fails only on mipsel is a
ude
searchindex.js clamav-0.103.5+dfsg/debian/changelog
clamav-0.103.6+dfsg/debian/changelog
--- clamav-0.103.5+dfsg/debian/changelog 2022-01-13 21:49:00.0
+0100
+++ clamav-0.103.6+dfsg/debian/changelog2022-05-26 10:17:16.0
+0200
@@ -1,3 +1,20 @@
+clamav (0.103.
searchindex.js clamav-0.103.5+dfsg/debian/changelog
clamav-0.103.6+dfsg/debian/changelog
--- clamav-0.103.5+dfsg/debian/changelog 2022-01-13 21:51:03.0
+0100
+++ clamav-0.103.6+dfsg/debian/changelog2022-05-26 10:19:13.0
+0200
@@ -1,3 +1,20 @@
+clamav (0.103.6+dfsg-
On 2022-05-20 13:07:55 [+0200], Jérémy Lal wrote:
> nodejs dynamically links to openssl, and since openssl >= 3,
> on mipsel, some of its tests are failing, see
> https://buildd.debian.org/status/package.php?p=nodejs
>
> The failures look like openssl was configured with no-err, e.g:
>
On 2022-05-16 22:38:44 [+0200], Jérémy Lal wrote:
> Last time so many openssl-related test failures happened,
> OPENSSL_CONF env was set to a relative path, and nodejs/openssl3
> expected an absolute path.
I don't understand why mipsel is different here. The init looks okay. I
copied the .cnf
On 2022-05-16 17:15:29 [+0200], Julien Cristau wrote:
> Hi,
Hi,
> The failures happen in parts of the test that spin up and attempt to
> connect to a TLS1.0 or TLS1.1 server. It used to pass on 1.1.1n and (I
> think) 1.1.1o.
That is something I don't understand.
> Trying to replicate with
On 2022-02-27 23:37:35 [+], Luca Boccassi wrote:
> This is known and expected, this package is an engine for OpenSSL 1.x.
> The 3.x version is shipped as a separate and different project, already
> uploaded to experimental:
>
> https://tracker.debian.org/pkg/tpm2-openssl
>
> Once OpenSSL 3.x
101 - 200 of 1863 matches
Mail list logo
