package: libxcrypt
version: 1:4.4.22-1
severity: serious
justification: breaks login
See bug #992848.
Because of the way libpam0g calls libxcrypt any existing sha256 hash
will be rejected at login as expired.
I'm going to fix this in pam using the linux-pam upstream fix, but
libxcrypt should not
> "Paul" == Paul Menzel writes:
Paul> Dear Mattias, Thank you for the analysis. I hit this too, and
Paul> GDM autologin did not work anymore [1], so users thought
Paul> Debian crashed during startup. Switching to tty2 and logging
Paul> in and changing the password there,
> "Ray" == Ray Klassen writes:
Ray> Package: libpam0g Version: 1.4.0-9 Severity: important Tags:
Ray> d-i X-Debbugs-Cc: rklas...@communitascare.com
Ray> Dear Maintainer,
How is this a d-i bug?
Paul> The VCS repository for this package unfortunately is at
Paul> 1.4.0-1, while 1.4.0-9 is shipped with Bullseye. Could you
Paul> please update the repository in question?
The current commits are at https://salsa.debian.org/hartmans/pam
and a merge request asking for these to be
>>>>> "Sean" == Sean Whitton writes:
Sean> On Thu 12 Aug 2021 at 11:47PM +02, Cyril Brulebois wrote:
>> Sean Whitton (2021-08-12):
>>> On Tue 27 Jul 2021 at 08:41AM -06, Sam Hartman wrote:
>>>
>>> >
> "Cyril" == Cyril Brulebois writes:
Cyril> Hi, Felix Lechner (2021-07-26):
Cyril> cc-ing debian-policy@ for some possible feedback.
Cyril> I'm not sure why we should be spending time tracking down
Cyril> Policy changes in (source for) udeb packages… so adding then
>>>>> "Benjamin" == Benjamin Kaduk writes:
Benjamin> On Wed, Jul 21, 2021 at 10:01:23AM -0600, Sam Hartman wrote:
>> control: severity -1 important
>>
Salvatore> The following vulnerability was published for krb5.
>>
control: severity -1 important
Salvatore> The following vulnerability was published for krb5.
Salvatore> CVE-2021-36222[0]: | sending a request containing a
Salvatore> PA-ENCRYPTED-CHALLENGE padata element | without using
Salvatore> FAST could result in null dereference in the
in the multiarch path.
+
+ -- Sam Hartman Fri, 09 Jul 2021 10:55:02 -0600
+
+pam (1.4.0-8) unstable; urgency=high
+
+ [ Hideki Yamane ]
+ * debian/patches-applied/lib_security_multiarch_compat
+- Fix regression introduced in 1.4.0-1: search both /lib/security and
+/lib/[multiarch_tripple]/security
package: libpam0g
version: 1.4.0-1
severity: important
In the merge of upstream 1.4.0, we lost the ability to read
/lib//security and only support /lib/security/multiarch_path.
Steve says that this was not an intentional change; it appears to be a
regression that affects software both inside and
control: clone -1 -2
control: retitle -2 mis-merge in patches prevents reading /lib/security
control: reassign -2 pam
control: found -2 1.4.0-1
control: severity -2 important
control: severity -1 serious
Steve said that it was not an intentional change to prevent finding pam
modules in
> "Steve" == Steve Langasek writes:
Steve> For the record, I did not intentionally drop those lines,
Steve> this was a matter of a mis-merge.
Okay, if it was a miss-merge, let's see if we can fix.
I'm reasonably busy this morning but will try to prepare something later
today based
> "Hideki" == Hideki Yamane writes:
>> I think Steve is quite familiar with multiarch and while he
>> hasn't commented yet I'm assuming he dropped those patch lines as
>> part of removing unnecessary upstream deltas.
Hideki> I want his comment, too.
Okay, let's hold off
> "Hideki" == Hideki Yamane writes:
control: tags -1 -patch -pending
I NACK this proposed NMU.
This many years after multiarch, I think it is entirely reasonable for
PAM to drop support for non-multiarch paths at the transition between
buster and bullseye.
As I said earlier in the bug, I'm
> "Rowan" == Rowan Wookey writes:
Rowan> Fair enough, I couldn't find any docs on the policy of
Rowan> /lib/security or any news on it not being scanned in
Rowan> Bullseye, is there something about that somewhere?
I don't know.
I had mostly been not paying attention to PAM but
control: reassign -1 libpam-yubico
control: severity -1 grave
control: retitle -1 pam_yubico fails to install module in multiarch path
control: found -1 2.23-1
> "Rowan" == Rowan Wookey writes:
Rowan> It appears that in Bullseye pam isn't checking /lib/security.
control: tags -1 confirmed
> "Johannes" == Johannes 'josch' Schauer writes:
Johannes> Hi,
Johannes> since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when
Johannes> invoking maintainer scripts. Usually that variable is
Johannes> empty but when calling dpkg with --root and
> "Johannes" == Johannes 'josch' Schauer writes:
I took a look at the references in the bug.
In particular, https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap
My goal was to try and do homework prior to a call.
Here's where I got:
That page actually seems to talk about a different
> "Bastian" == Bastian Germann writes:
Bastian> There are H.264 patents that are applicable. I do not know
Bastian> how the existing H.264 implementations in Debian handle
Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ,
Bastian> these seem to be ignored.
I
> "Will" == Will Gnann writes:
>* What exactly did you do (or not do) that was effective
> (or ineffective)?
Will> I have updated the krb5-user version to the
Will> testing one and it does not solve the problem. I read the
Will> source code and the correct behavior seems
> "Stephan" == Stephan Lachnit writes:
Stephan> BSD-2-Clause Programming Lang: C Description :
Stephan> micro-compositor for games
Stephan> Will maintain in Games team.
Stephan> Description on GitHub:
Stephan> In an embedded session usecase, gamescope does the same
control: tags -1 confirmed
> "Andreas" == Andreas Beckmann writes:
Andreas> Is krb5-doc missing a Depends/Recommends/Suggests:
Andreas> libjs-sphinxdoc, libjs-jquery, libjs-underscore ?
Looks like.
Will fix post-release.
signature.asc
Description: PGP signature
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> On Sat 03 Apr 2021 at 09:25AM -07, Russ Allbery wrote:
>> To be clear, my understanding of the advocacy of using non-native
>> packages is primarily about their impact on *Debian* workflows
>> (being able to base
> "Russ" == Russ Allbery writes:
Russ> Russ Allbery writes:
>> In attempting to revise recent GRs to use the same terminology as
>> Policy, I got frustrated again by the lack of precision of our
>> current language. This is an attempt to make a minor
>> improvement. It
> "Russ" == Russ Allbery writes:
Russ> Hi Sam,
Russ> Thanks for the review! There's now a newer version of this
Russ> diff adjusted for a flaw that Simon pointed out. It's
Russ> sufficiently different from the original diff that I don't
Russ> want to count seconds for
I do not support advising against using native packages with our current
tooling.
My issue is that for some work flows generating and keeping up with the
upstream tarballs significantly increases the frustration of packaging
and and brings doing a package update across a pain threshhold that
> "Russ" == Russ Allbery writes:
Russ> Here is an updated diff that documents the most
Russ> well-understood version conventions in the Debian archive.
Russ> More could certainly be added; this is just a first start that
Russ> addresses this specific bug.
Russ> This
5crypto3 toward other internal libraries because
+of removed internal symbols, Closes: #985739
+
+ -- Sam Hartman Sun, 28 Mar 2021 13:43:01 -0400
+
krb5 (1.18.3-4) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 55fea8c334..c0e10fe25d 100644
--- a/debian/contr
control: tags -1 confirmed
I haven't explicitly reproduced this, but based on the description I am
confident this is an issue.
What happened is that upstream dropped an internal symbol
krb5int_c_combine_keys that is used by the old library.
So once libk5crypto3 is upgraded, libkrb5-3 breaks.
control: tags -1 wontfix
This is a duplicate of a wontfix bug.
Don't have time to go look up the other bug now.
this unless the user has overwridden the configuration
+- Fix capitalization of pam_Tally in debconf description
+
+
+ -- Sam Hartman Mon, 15 Mar 2021 15:01:55 -0400
+
pam (1.4.0-6) unstable; urgency=medium
* Clearly it's been too long since I've done debconf; run
diff --git a/debian
> "helix84" == helix84 writes:
helix84> .po attached
I'm a bit confused.
This po looks identical to the one I received from
Ladislav the other day and already checked in.
(I didn't tag it pending because there was not a bug)
Is there supposed to be a difference or are you just
Hi.
Thanks for your reply.
The links to bugs you included add much needed detail to this
discussion.
> "Matthias" == Matthias Klose writes:
Matthias> as pre-processing. So we know since about three years
Matthias> that dwz doesn't support compressed debug symbols. Your
> "Matthias" == Matthias Klose writes:
Matthias> Maybe you should be more specific about "those who can't
Matthias> use" uncompressed debug info in the first place.
So, you've argued that the disk savings are not significant inside a
package, because packages are themselves
> "Martin" == Martin Schurz writes:
Martin> I have added pam_tally to common-auth and the upgrade did
Martin> not stop when installing the new libpam-modules. I believe
Martin> the regex is missing these files, since it does not contain
Martin> a "-" in the permitted
> "Helmut" == Helmut Grohne writes:
Helmut> The thing I was proposing to change here was making it
Helmut> produce the host architecture -L flag without exporting CC
Helmut> at the cost of sacrificing "Multi-Arch: same"
Helmut> (i.e. coinstallability of krb5-multidev with
Ah, I understand.
so, a couple of things to consider.
First, some of the headers in krb5-multidev aregenerated and are not
guaranteed to be the same between the host and build.
So, the official interface is that you had better use the right
krb5-multidev or you might be very sad.
In practice, I
I definitely think your solution is fine and is the best bullseye
solution.
I'm a bit confused about your proposed change to krb5-config.
People search for krb5-config by that name not with a multiarch tripple.
If that became multi-arch dependent, how would you install more than
one set of krb5
In adapting your first patch, I narrowed things down a bit.
I search /etc/pam.d files containing only a-z0-9A-Z, which I believe
should catch all the active pam.d files but not editor backups, .pam-new
files and the like.
I also specifically recommend looking at pam_faillock.
--Sam
I'm setting a calendar note to come back tho this in May.
Apologies for not having time sooner; I'm in the middle of planning for
a move and trying to deal with bullseye issues.
control: tags -1 wontfix
I'm not at all convinced this is a good idea. We're replacing a great,
well-tested facility--namely running maintainer scripts in root
directories with a mechanism that requires support to be spread through
each package.
I appreciate that this approach has the support
Mon Sep 17 00:00:00 2001
From: Sam Hartman
Date: Wed, 24 Feb 2021 14:29:53 -0500
Subject: [PATCH] debian/libpam-modules.preinst|templates: pam_tally
deprecation
* Add a facility to detect enabled profiles that contain a particular module
* If a profile contains an enabled module that is be
> "Paul" == Paul Gevers writes:
Paul> Just to elaborate, that set is frozen because bits that
Paul> influence a lot of builds can become difficult to manage if a
Paul> bug sneaks in. So it's good to discuss here how much pam can
Paul> influence the built artifacts. Hence,
>>>>> "Paul" == Paul Gevers writes:
Paul> On 23-02-2021 19:17, Sam Hartman wrote:
>> This is just a FYI, opened as a bug because you've expressed a
Paul> If it's in time to migrate before March 12, there's nothing to
Paul> unblock.
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: vor...@debian.org
Hi. I'm writing with my pam uploader hat on to give you a heads up about two
issues that are kind of nasty and affect upgrades. This is just a FYI, opened
as a bug because you've expressed a preference for that
> "Lars" == Lars Kruse writes:
Lars> I am inclined to think, that enabling "mkhomedir" for
Lars> non-interactive sessions as part of the "mkhomedir"
Lars> configuration shipped by the pam package would not hurt its
Lars> users. But maybe I am overlooking something ovious?
It
> "Martin" == Martin Schurz writes:
>> It looks like Steve had an explicit reason for disabling
>> pam_tally here and I don't want to go second guess that. (Steve,
>> if I'm wrong, please chime in). In particular, Steve kept
>> pam_cracklib, which also requires an extra
It looks like Steve had an explicit reason for disabling pam_tally here
and I don't want to go second guess that.
(Steve, if I'm wrong, please chime in).
In particular, Steve kept pam_cracklib, which also requires an extra
option, but did not keep pam_tally.
I also think there is another wrinkle
> "Martin" == Martin Schurz writes:
Hi. I apologize for taking a while to come up to speed on this and for
a couple of false starts. It's been a while since pam has been a major
focus of mine, but I offered to help Steve out so I'm coming back up to
speed.
I agree that we cannot comment
Mostly for anyone else subscribed to the pam bug reports.
How do I want to detect a systemd native unit. I don't think I want to
look in the filesystem; do we need to do anything more complex than
looking at the UnitState in systemctl is-enabled?
What is Debian's
preferred way to determine if a
> "Lucas" == Lucas Nussbaum writes:
Lucas> When using config snippets in /usr/share/pam-configs/, it
Lucas> seems that 'Session-Interactive-Only: no' is equivalent to
Lucas> 'Session-Interactive-Only: yes'.
I think we've missed the freeze deadline for fixing this in bullseye.
Hi.
So, you seem to be thinking about thnigs a bit differently than I am.
I took a few days to come up to speed.
It sounds like you're assuming that someone will add pam_tally or
pam_pam_tally2 using a package profile in /usr/share/pam-configs.
I was assuming someone would add pam_tally or
package: libpam-runtime
version: 1.4.0-3
severity: important
When I made modifications to the common-* templates, I needed to update
the list of md5sums in pam-auth-update to avoid breaknig future
upgrades.
Fortunately, as I read the code, this ca nbe fixed in a future version
without ill effects
Why wouldn't we just comment out the lines in the upgrade rather than
blocking the upgrade?
> "Sean" == Sean Whitton writes:
Sean> Hello,
Sean> So, just to confirm, you're saying that you think that you or
Sean> people you know would end up doing the latter pretty regularly
Sean> if we were to decide to turn off compression?
I know for larger packages I'd be likely
control: tags -1 confirmed
> "Francesco" == Francesco Paolo Lovergine writes:
Francesco> Syslog warns about that.
Francesco> systemd[1]: /lib/systemd/system/krb5-kdc.service:7:
Francesco> PIDFile= references a path below legacy directory
Francesco> /var/run/, updating
> "Adam" == Adam Borowski writes:
Adam> Well, the problem I was fixing was patches not being applied
Adam> -- which obviously broke installability.
I understand now and regret my previous frustration.
Thanks for working with me.
So, it seems like we have a couple directions we
> "Adam" == Adam Borowski writes:
Adam> I think we should _always_ trigger a rebuild, to make sure the
Adam> source we provide is the real source.
I'm really incredibly frustrated reading the above.
I doubt that was your intent, but here's what happened from my
standpoint.
I asked
In your NMU of pam 1.1.8-3.4, you moved the xsl build dependencies from
build-depends-indep to build-depends.
This effectively enables rebuilding of man pages even for binary package
builds. It looks like the goal was to work around problems in
multi-arch installability.
But I don't see how it
> "Christoph" == Christoph Anton Mitterer writes:
Christoph> Wouldn't it then be a better choice to wait for the
Christoph> availability of argon2?
Christoph> Not that'd I'd have any insight on whether yescrypt is
Christoph> much worse, but Argon2 is simply the winner and
package: release-notes
x-debbuggs-cc: p...@packages.debian.org
Hi. I've never filed one of these before, and I'm in the middle of
several other things, so I decided to file the bug even if I get it not
quite right rather than forgetting.
Pam 1.4.0-3 changes the default password hash to
> "Christoph" == Christoph Anton Mitterer writes:
Christoph> Hey. I'd guess that the long term plan is then to switch
Christoph> to Argon2?
Christoph> May I suggest in advance that this is then added to
Christoph> NEWS.Debian with the hint that people might perhaps want
Josh, I took a look at writing a patch to implement dlopen of the
appropriate RPC libraries for NIS support in pam.
It looked a bit more thorny than I'd feel comfortable with unless I had
substantial review, and it looks like my non-Debian commitments are
picking up.
Thoughts:
* If it's
> "Allison" == Allison Karlitskaya writes:
Allison> An additional problem is that faillock requires a
Allison> tmpfiles.d fragment to be installed to create the
Allison> /run/faillock directory, because the module won't create it
Allison> for itself if it's missing.
I
I included what on second thought is a somewhat broken fix for this in
an upload of pam 1.4.0-3.
My fix is broken in that I got the upgrade and removal sequence of
prerm confused (I thought prerm was called with remove
on upgrade rather than
on upgrade.
So, my change has the affect of
I think it would be valuable to get pam_limits into common-session.
I think the reason we didn't do it back in the day was that we didn't
have as clear of a common-session vs common-session-noninteractive
distinction.
That said, I think it's way too late in the bullseye cycle to do this.
I'm
reassign 932752 gawk
retitle 932752 gawk should pre-depend on shared libraries
thanks
Hi. The interesting diagnosis is in the last message from Steve.
What's happening is that on a stretch->buster upgrade, gawk is
unpacked, because it is pre-depended by an essential package
(base-files), but
> "Santiago" == Santiago Garcia Mantinan writes:
>> 1) eno1 is connected directly to a wifi router. I get an IPv6
>> address using router advertizements.
>>
>> But if I insteade slave that interface to a bridge say iface
>> brint inet dhcp bridge-ports eno1 auto brint
The setup that does not work for me (and that I don't currently have
access to is)
Works:
1) eno1 is connected directly to a wifi router.
I get an IPv6 address using router advertizements.
But if I insteade slave that interface to a bridge say
iface brint inet dhcp
bridge-ports eno1
auto
General arguments about how the TC should conduct its business do not
belong on this bug.
I'd appreciate it if replies to this message are directed to a different
place than this bug.
We've established that the TC is operating consistently both with its
historical process and with currently
> "Helmut" == Helmut Grohne writes:
>> If I don't get to this soon in the bookworm cycle, feel free to
>> remove the build-depends yourself; it's debian group writable in
>> salsa.
Helmut> Would there be issues with committing it to git right now?
Helmut> That way, it
As I understand the freeze, it's too late for bullseye because krb5 is
in the build-essential set.
If I don't get to this soon in the bookworm cycle, feel free to remove
the build-depends yourself; it's debian group writable in salsa.
--Sam
Hi.
Here's what I've found so far.
https://askubuntu.com/questions/460405/ipv6-does-not-work-over-bridge
This answer suggests that it's IGMP snooping *not* STP that is the
problem.
That makes a lot more sense to me, and has an obvious fix:
* Either disable IGMP snooping
or
* Enable an IGMP
Looking into it.
--Sam
package: bridge-utils
severity: important
version: 1.6-3
justification: breaks actual switches that need v6
In 736336 , you documented that stp breaks ipv6. As was pointed out in
the bug report that's kind of bogus. You clearly need both in some
situations. As an example, if you are actually
package: bridge-utils
version: 1.6-3
severity: important
justification: breaks network connectivity on release upgrade
It looks like this is a kernel change not a bridge-utils change.
But the way MACAddress selection for the bridge works has changed
between buster and bullseye.
The result is
> "Russ" == Russ Allbery writes:
>> I have not come to the TC to ask them to overrule the maintainer
>> frivolously nor before exploring as many other options as I
>> could.
Russ> I understand (oh, boy, do I ever) how strained relationships
Russ> are after the
> "Marco" == Marco d'Itri writes:
Marco> On Jan 02, Steve Langasek wrote:
>> So, can you provide more rationale why you think this should be
>> the default?
Marco> Because yescrypt is the best password hashing algorithm
Marco> available in libxcrypt and its default.
> "Josh" == Josh Triplett writes:
Josh> I'm happy to contribute towards any of these paths, or another
Josh> path that would avoid expanding the pseudo-Essential set.
Josh, I found your message fairly frustrating, because you jumped
immediately to the assumption that we want to
> "Russ" == Russ Allbery writes:
Russ> We do drop features all the time between stable releases,
Russ> though, and generally that too is at the maintainer's
Russ> discretion. The package maintainer's normal obligation in
Russ> Debian isn't to keep everything working that
> "Russ" == Russ Allbery writes:
Russ> I think this clearly and unambiguously says that maintainers
Russ> can depend on unit support and drop init scripts from their
Russ> packages if they so choose, and that this choice only requires
Russ> as much justification as rejecting
>>>>> "Wouter" == Wouter Verhelst writes:
Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
>> I think that we should either decide that
>>
>> 1) NetworkManager should support elogind
>>
>> or
> "Josh" == Josh Triplett writes:
Josh> I realize that this is an essential package, but it does have
Josh> a prerm and postrm script, and on a system with absolutely no
Josh> usage of PAM it should be posible to remove without
Josh> encountering an infinite loop like this.
I
>>>>> "Matthew" == Matthew Vernon writes:
Matthew> On 15/12/2020 22:07, Sam Hartman wrote:
>>> However, Debian remains an environment where developers and
>>> users can explore and develop alternate init systems and
>>&
I had a great discussion with Mark Hindley about this issue a few months
ago.
I'd like to summarize what I said in that discussion as input to the TC.
But I'd also like to start out by reminding us all what we said in the
GR text that we agreed to.
As one of the contributors to that text, you
> "Bill" == Bill Allombert writes:
Bill> Let us be honest with ourselves: what matter for most purpose
Bill> is the position of the ftp-master team that processes the NEW
Bill> queue. What policy says is secondary.
I absolutely agree we should coordinate appropriately with the
> "Russ" == Russ Allbery writes:
Russ> That said, I tend to be hyper-conservative and nit-picky about
Russ> things like this, accurately representing copyright years
Russ> isn't in my top thousand things I want people to work on in
Russ> Debian, and I'm highly dubious that it
Here's my take on the discussion so far.
And I want to stress that I am not a policy editor, and to the extent
that they read the discusssion differently than I do, their reading
controls.
* Russ and I would be willing to accept either outcome--either you can
collapse years or you cannot.
*
> "Ansgar" == Ansgar writes:
Ansgar> using other choices of "Rules-Requires-Root" than "no" and
Ansgar> "binary-targets". The query [1] found two uses:
Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have
package: libapache-mod-auth-kerb
severity: serious
version: 5.4-2.4
tags: security
justification: unmaintained with security weaknesses
Hi. As part of a recent krb5 transition, I took a look at
libapache-mod-auth-kerb.
As part of that transition, libapache-mod-auth-kerb was removed from
control: tags -1 pending
I've uploaded to delayed/3, using your minimal patch.
Thanks.
--Sam
I'd like to see people chime in who have not participated in the
discussion yet.
I prefer your original text but we'd need to get support for it.
It sounds like we're fairly evenly split among the current participants
in the issue.
--Sam
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.
control: tags -1 patch
Here's a patch that I believe will get libapache-mod-auth-kerb working
with the latest krb5. I'll go upload a krb5 that fixes the breaks
relationship.
I'd appreciate it if someone who actually uses libapache-mod-auth-kerb
will test this patch.
If it gets tested, I'll NMU.
> "Russ" == Russ Allbery writes:
Russ> Marc Haber writes:
Russ> The years are an annoying bit of pedantry. The short version
Russ> is that US copyright law requires a year in the notice, and
Russ> that year is supposed to represent a year in which a
Russ> copyrightable
> "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
control: reassign -1 libapache2-mod-auth-kerb
control: found -1 libapache2-mod-auth-kerb/5.4-2.4
control: retitle -1 FTBFS with krb5 1.18: significant use of internal
APIs and data structures
control: affects -1 libkrb5-3
Hi.
Kerberos 5 1.18 significantly refactors the replay cache
>>>>> "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/dat
> "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
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
201 - 300 of 1322 matches
Mail list logo
