Hi,
I just wanted to add that the patch that Ubuntu uses for dovecot comes
from redhat (and fedora)
https://bugzilla.redhat.com/show_bug.cgi?id=1962035 it seems to work
well for them. Feels like a better option then edit config to work with
openssl1, as this will break as soon as an user
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 Sun, Jun 05, 2022 at 08:44:22PM +0200, Sebastian Andrzej Siewior wrote:
> 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
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
Hi Sebastian
On 2022-05-28 16:49:07, Sebastian Ramacher wrote:
> On 2022-05-27 15:36:53 +0200, Kurt Roeckx wrote:
> > On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote:
> > >
> > > That leaves #1011051. What's your view on that bug?
> >
> > So my understanding is that 1.1.1
On Sun, 2022-06-05 at 19:37 +0200, Paul Gevers wrote:
> Hi,
>
> On 05-06-2022 19:35, M. Zhou wrote:
> > > But if this is really the result of the rebuild. I think we just
> > > discovered a serious flaw. The alternative dependency on libluajit-5.1-2
> > > just lost its version constraint, as it's
Hi,
On 05-06-2022 19:35, M. Zhou wrote:
But if this is really the result of the rebuild. I think we just
discovered a serious flaw. The alternative dependency on libluajit-5.1-2
just lost its version constraint, as it's only added to libluajit2-5.1-2.
U... Yes, that's a good catch.
I
On Sun, 2022-06-05 at 11:43 +0200, Paul Gevers wrote:
>
> > sbuild --no-clean -c sid -d unstable love_11.3-1.dsc --extra-package
> > ../luajit.pkg/
> > debc love_11.3-1_amd64.changes
> >
> > Package: love
> > Version: 11.3-1
> > Architecture: amd64
> > Maintainer: Debian Games Team
> >
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
This bug is follow-up for this thread:
https://lists.debian.org/debian-release/2022/06/msg9.html
The original LuaJIT upstream does not care about IBM architectures, which
causes
Hi Mo,
On 05-06-2022 05:28, M. Zhou wrote:
Please see deb-symbols(5), the symbols control file contains a
part supporting advanced usage that not all Debian developers know:
That was indeed a missing piece.
Then I rebuild it against with the above luajit commit pending
to upload:
sbuild
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi RMs,
Transition request to show my intentions and track what's blocking.
Two packages, balboa and python-rocksdb are affected with the rocksdb
7.2.2 transition. The former builds
11 matches
Mail list logo
