On 2020-11-23 10:22:21 -0500, Sam Hartman wrote:
> I've proposed a patch to libapache-mod-auth-kerb.
> If someone tests the patch, I'll NMU.
>
>
> mia-query on the maintainer of libapache-mod-auth-kerb is revealing;
> I'll contact the MIA team and suggest orphaning or removing
>
I've proposed a patch to libapache-mod-auth-kerb.
If someone tests the patch, I'll NMU.
mia-query on the maintainer of libapache-mod-auth-kerb is revealing;
I'll contact the MIA team and suggest orphaning or removing
libapache-mod-auth-kerb.
On Sat, 21 Nov 2020 01:51:27 + Paul Wise wrote:
> We are using libapache2-mod-auth-kerb at my workplace, I've raised an
> issue about taking over modauthkerb upstream or just switching to
> another module
We have decided to switch to the gssapi module.
I would recommend that
> "Paul" == Paul Wise writes:
Paul> switching to another module but I suspect that modauthkerb
Paul> should just get removed from Debian in favour of
Paul> mod_auth_gssapi, which is supposed to be a replacement.
I think that mod_auth_gssapi plus mod_auth_pam and libpam-sss or
On Fri, Nov 20, 2020 at 7:45 PM Sam Hartman wrote:
> I note that libapache2-mod-auth-kerb seems to be QA maintained
> effectively in Debian.
> I haven't looked at upstream to see if they have a fix.
Upstream is basically unmaintained, despite still having users.
We are using
> "Sam" == Sam Hartman writes:
> "Sebastian" == Sebastian Ramacher writes:
>>> I've uploaded to unstable. There's what tracker lists as a
>>> regression in CI tests:
>>>
https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
>>>
>>> I don't
> "Sebastian" == Sebastian Ramacher writes:
>> I've uploaded to unstable. There's what tracker lists as a
>> regression in CI tests:
>>
https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
>>
>> I don't think that regression looks caused by
Control: block -1 by 975344
On 2020-11-20 13:04:06 -0500, Sam Hartman wrote:
> I've uploaded to unstable.
> There's what tracker lists as a regression in CI tests:
> https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
>
> I don't think that regression looks caused by
Processing control commands:
> block -1 by 975344
Bug #974982 [release.debian.org] transition: krb5
974982 was not blocked by any bugs.
974982 was not blocking any bugs.
Added blocking bug(s) of 974982: 975344
--
974982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974982
Debian Bug
I've uploaded to unstable.
There's what tracker lists as a regression in CI tests:
https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
I don't think that regression looks caused by krb5 after examining the
log.
Do you need me to request binnmu of
Processing control commands:
> tags -1 + confirmed
Bug #974982 [release.debian.org] transition: krb5
Added tag(s) confirmed.
> forwarded -1 https://release.debian.org/transitions/html/auto-krb5.html
Bug #974982 [release.debian.org] transition: krb5
Set Bug forwarded-to-address to
Control: tags -1 + confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-krb5.html
On 2020-11-17 10:07:48 -0500, Sam Hartman wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi. I've
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi. I've uploaded krb5 1.18 to experimental, and the soname of the
administrative libraries (and libkdb5, but that's purely internal)
changed. The ABI differs, but the API is the same.
13 matches
Mail list logo
