ld of endeavor. In other words, such a license
would not be DFSG free.
--Sam
signature.asc
Description: PGP signature
> "Chris" == Chris Hofstaedtler writes:
Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.
T
I'm not convinced this is critical, but it is some varient of RC.
Proposed solution is to rebase the hurd patch (gbp pq import; git rebase
-i; edit the commit) to modify the top level meson.build to include the
header test.
Then gbp pq export and commit the modified patches.
If someone gets to t
>>>>> "Adrian" == Adrian Bunk writes:
Adrian> Sam, could you make a maintainer upload with this change?
Adrian> krb5 is quite central in the OpenLDAP transition that just
Adrian> started.
Absolutely, thanks for the ping. Will get to it now.
> "Lucas" == Lucas Nussbaum writes:
> install: cannot change ownership of
> 'debian/krb5-admin-server/usr/sbin/krb5_newrealm': Operation not permitted
It looks like this is a result of defaulting to rules-requires-root: no
(was that change in your rebuild?)
I think that I need to set rules-
> "Helmut" == Helmut Grohne writes:
Helmut> In bullseye and earlier, I guess it works.
Helmut> If you start with bullseye or earlier, upgrade to bookworm
Helmut> and then to trixie, it continues to work, because the dash
Helmut> maintainer scripts preserve any diversion that
Follow up:
As a work-around, the following seems to get things to work again (not
tested in-depth though):
Change line /usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py:32
from
_deactivated = True
to
_deactivated = False
This allows at least to hg command to be calle
So, I have now two machines where this bug happens, but on a third one
(my notebook) there seems to be no problem, despite all of them showing
6.8-1 as the installed version (via `dpkg --list | grep mercurial`).
Any recommendations how to make a differential-diagnosis between two
systems? I think
Confirmed, this might render any mercurial server unusable in the
future.
signature.asc
Description: signature
package: krb5-kdc
severity: grave
version: 1.21.3-2
A typo in version 1.21.3-2 incorrectly interrupts the configure args,
among other things causing sysconfdir to be incorrectly set.
This breaks krb5-kdc because it does not read /etc/krb5kdc/kdc.conf.
Found by CI tests.
signature.asc
Descriptio
g with more gratuitous environment changes entirely
outside my control.
I'm kind of tempted to take this to the TC and ask for clarity about
what is reasonable to expecte from buildds.
--Sam
> "Chris" == Chris Hofstaedtler writes:
Chris> When building krb5 with sbuild, configured to use the unshare
Chris> backend, the t_iprop.py test apparently times out without any
Chris> output.
I'm guessing, but have not confirmed that sbuild unshare is setting up a
network namesp
e rationale for this goes back to the Kerberos standard (RFC 4120).
--Sam
control: tags -1 +help
Chris> Filing with severity: serious as the buildd network has
Chris> started switching to sbuild with unshare backend, and
Chris> multiple people have reproduced this problem.
I'm not running sbuild these days; I'm mostly moving toward
containerized builds fo
>>>>> "Steve" == Steve Langasek writes:
Steve> Hi Sam,
Steve> I've run into a problem with openldap not being
Steve> bootstrappable for the time_t transition because it
Steve> build-depends on krb5-kdc, and krb5-kdc is uninstallable
at
all or if you did, but we're more focused on people who never upgraded.
If you do run into breakage, we'll work with you to find a solution.
--Sam
package: pam
version: 1.5.3-5
severity: serious
This version of pam drops pam_userdb which can break systems that use
pam_userdb in their configuration. Long term we do want to split it out
and possibly drop. However, this change is purely for the time_t
transition and will be reverted.
This ve
ue
and deployed changes like this in production.
Steve and I agreed to revert the rename on IRC, effectively accepting
the ABI break because it doesn't matter for the archive.
We may look at better solutions when we have a bit of time.
--Sam
signature.asc
Description: PGP signature
that possible on arches
where the ABI has actually changed.
On arches where the ABI is the same, libpam0t64 provides libpam0g, so we
can get rid of libpam0g today.
--Sam
> "Simon" == Simon McVittie writes:
Simon> It might be relevant that according to #972151, arm-conova-03
Simon> (and perhaps other *-conova-* buildds?) is IPv6-only, with no
Simon> IPv4 addresses or routes other than loopback (not even via
Simon> NAT).
Simon> I believe th
Helmut> be worth a go?
Steve and I are unaware of usage in Debian either.
--Sam
signature.asc
Description: PGP signature
> "Helmut" == Helmut Grohne writes:
Helmut> pam also runs in to /usr-move breakage. This one looks
FYI, I have some time scheduled to deal with this tomorrow morning
US/Mountain (late in the day for Europe).
> "Helmut" == Helmut Grohne writes:
Helmut> pam fails to build from source in unstable, because quilt no
Helmut> longer recognizes the QUILT_PATCHES_DIR variable and
Helmut> therefore does not find a series file. Renaming it to
Helmut> QUILT_PATCHES fixes the build.
I applied
er
refine what builds are allowed to do if you think that something krb5 is
doing is not reasonable.
I suspect this is a case where your build environment does not mirror
the buildds enough for the tests to succeed, but I'm leaving the bug
open for your input.
--Sam
> "Tianyu" == Tianyu Chen writes:
Tianyu> During a local rebuild of krb5, your package failed to
Tianyu> build.
So, I'm guessing this is related to the upgrade in Debian from doxygen
1.9.4 to 1.9.8.
The krb5 build process uses doxygen to generate an xml representation of
the docume
> "Andreas" == Andreas Beckmann writes:
Andreas> The fix should be easy: your package is using adduser or
Andreas> deluser from the adduser package, which is only priority
Andreas> important. Using useradd or userdel from the passwd package
Andreas> (priority required) should f
me.
Thanks for that.
If I've mischaracterized the severity of the potential harm above, let
me know.
I don't want a broken pam, but I also consider this kind of move
moderate risk.
--Sam
control: tags -1 wontfix
> "bigon" == bigon writes:
bigon> It seems that your package libpam-modules-bin is shipping
bigon> files (.service, .socket or .timer) in
bigon> /usr/lib/systemd/system.
I think we're talking about pam_namespace.service.
I don't think dh_installsystemd
> "Theodore" == Theodore Ts'o writes:
Theodore> So enabling what may be convenient, but ultimately an
Theodore> anti-pattern is something that hopefully in the long-term
Theodore> Debian should be trying to *avoid*.
That's certainly true.
I am not entirely convinced that using c
> "Adrian" == Adrian Bunk writes:
Adrian> Below is my attempt to give an overview of the situation,
Adrian> feel free to amend/correct if anything is missing or wrong.
I believe your summary is correct and includes the issues I am aware of.
I believe I am following things enough tha
Replying off list, because I don't think it matters much for the RT
discussion.
> "Russ" == Russ Allbery writes:
Russ> Yes, I'm probably understating the difficulty of making this
Russ> change in practice inside image building software as it's
Russ> currently constructed.
R
> "Adrian" == Adrian Bunk writes:
Adrian> On Thu, Feb 16, 2023 at 05:48:22PM +0100, Daniel Leidert wrote:
>> Am Donnerstag, dem 16.02.2023 um 18:37 +0200 schrieb Adrian Bunk:
>> > On Wed, Feb 15, 2023 at 12:05:41AM +0100, Daniel Leidert wrote:
>> > > ... > > Reasons: > > ...
> "Sebastian" == Sebastian Ramacher writes:
Sebastian> To better understand the impact of this change, I was
Sebastian> wondering which tools / image builders in the archive
Sebastian> would be affected by this change. I've cloned the bug to
Sebastian> vmdb2, but what about o
>>>>> "Theodore" == Theodore Ts'o writes:
Theodore> On Wed, Feb 15, 2023 at 01:17:38PM -0700, Sam Hartman wrote:
>>
>> I.E. I think your question of "for how long" has a very simple
>> answer based on our history: if
> "Theodore" == Theodore Ts'o writes:
the answer to your "how long" is that packages
>> should also work with the kernel from the previous and the kernel
>> from the next Debian release.
Theodore> This isn't a problem with the kernel.
I don't think that was Adrian's point.
I thi
> "Moritz" == Moritz Mühlenhoff writes:
Moritz> Not moving to 6.1.x (which is most likely the next Linux
Moritz> kernel LTS) is by far a worse regression since it applies to
Moritz> every single Debian system.
Moritz> As a community distro without paid, full time kernel
Mo
> "Bastian" == Bastian Germann writes:
Bastian> The main license does not have a GPL version. However,
Bastian> there are several files licensed under specific (L)GPL
Bastian> versions and also other licenses included. Debian Policy
Bastian> requires to document every contain
[1] RFC8482 responds to ANY in such as way as to not break Qmail
On Sat, Nov 26, 2022 at 10:34 AM Sam Trenholme wrote:
>
> Upstream here again. I have released MaraDNS 3.5.0030 and 3.4.09 with
> a security update: MaraDNS now fully supports RFC8482, which means
> MaraDNS no longer
someone can not step up to plate to maintain MaraDNS for Debian, we
should deprecate and eventually remove the package.
I may end up making my own .deb files for MaraDNS.
-- Sam
On Mon, Nov 21, 2022 at 5:03 AM Moritz Muehlenhoff wrote:
>
> Source: maradns
> Version: 2.0.13-1.4
&
Upstream here. I should probably summarize the security issues post
2.0.13; MaraDNS is the authoritative server and Deadwood is the
recursive server:
- A theoretical issue with the cryptographic code which doesn’t affect
gcc and clang compiles of Deadwood.
- An issue where a clever attacker could
> "Salvatore" == Salvatore Bonaccorso writes:
Salvatore> We were originally thinking so (and Moritz added krb5 to
Salvatore> the DSA needed list), as at least for 32bit architectures
Salvatore> it might be possible to go beyond denial of service and
Salvatore> potentially lead
er conditions;
+CVE-2022-42898, Closes: #1024267
+
+ -- Sam Hartman Thu, 17 Nov 2022 12:41:46 -0700
+
krb5 (1.18.3-6+deb11u2) bullseye; urgency=medium
* Use SHA256 as Pkinit CMS Digest, Closes: #1017995
diff --git a/debian/patches/0014-Fix-integer-overflows-in-PAC-parsing.patch
> "Salvatore" == Salvatore Bonaccorso writes:
>> Will fix for unstable tomorrow.
Salvatore> Thank you.
>> I'm still trying to understand the practical impact. Do you
>> think you're going to want to issue a DSA for stable?
Salvatore> We were originally thinking so (and
> "Salvatore" == Salvatore Bonaccorso writes:
Salvatore> Hi,
Salvatore> The following vulnerability was published for krb5.
Salvatore> CVE-2022-42898[0]: | integer overflows in PAC parsing
Salvatore> If you fix the vulnerability please also make sure to
Salvatore> includ
> "Adrian" == Adrian Bunk writes:
Adrian> Dear maintainer,
Adrian> I've prepared an NMU for moonshot-trust-router (versioned as
Adrian> 3.5.4+1+nmu1) and uploaded it to DELAYED/2. Please feel free
Adrian> to tell me if I should cancel it.
This NMU looks good to me. Feel fre
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
Johannes> Hi,
Johannes> our CI runs for the DPKG_ROOT tests failed today because
Johannes> pam FTBFS. I rebuilt pam locally in a fresh sbuild chroot
Johannes> without any modifications and arrived at the same build
Package: debspawn
Version: 0.5.0-1
Severity: serious
Justification: Significant data loss
I used debspawn interact to interactively explore what I needed to do to get a
new upstream package building.
To make that easier, I mounted my source trees and debian working environment
in the container.
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 m
ttered throughout the day ions, but it sounded
like Benjamin Kaduk
might be available to help.
If not, I'll have some time and be back to general availability by
Sunday.
--Sam
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 /lib/securi
> "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 on
> "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 unti
> "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 h
> "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 it
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.
FYI linked issue and summary of issue from upstream perspective:
https://github.com/rsnapshot/rsnapshot/issues/279#issuecomment-860001348
/intro-maintainers (read 1-2, start at 3)
>
>
Hi Michael, I don't understand this. Wouldn't it be easier if you
orhpaned the package since it's already in stable?
Thanks,
Sam.
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.
In
> "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 character
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
7be83fd6167f02ad256 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 enabl
Package: podman
Version: 3.0.0~rc2+dfsg1-2+b1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s...@robots.org.uk
After upgrading to podman 3, I can't run any containers any more.
$ podman run --rm -it docker.io/library/debian:10
Error: failed to connect to container
This is due to improper use of setuptools_scm in docs/conf.py. This is
fixed [1] in version 0.16.8, along with other build errors. Please
consider packaging the new version.
[1]
https://github.com/pimutils/vdirsyncer/commit/b1214cd693d7a6c6693da3d070e8b9965a84a88e
Thanks Houben, I appreciate your efforts!
Sam
Quoting Rens Houben (2020-12-22 16:07:00)
> Hello,
>
> I've come across the same bug while trying to set up a new service at work.
>
> After some digging (we've currently got a mishmash of Jessie and Buster
> system
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
testing.
control: tags -1 pending
I've uploaded to delayed/3, using your minimal patch.
Thanks.
--Sam
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.
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 implementatio
Package: src:freeipa
Followup-For: Bug #970230
Control: tag -1 + patch
This should let freeipa build on armel again:
$ diff -u debian/rules.old debian/rules
--- debian/rules.old2020-11-11 13:26:32.112603329 +
+++ debian/rules2020-11-11 13:26:37.020620794 +
@@ -99,7 +99,7 @@
= /var/uwsgi
Sam
Quoting Vlastimil Zima (2020-11-06 15:36:47)
> Package: uwsgi-emperor
> Version: 2.0.19.1-3+b1
> Followup-For: Bug #969372
>
> Hi Thomas,
>
> indeed, I have a number of vassals configured, actually I use emperor
> for web development for several years now.
Source: sssd
Followup-For: Bug #965143
Control: -1 + fixed-upstream patch
Upstream things this is https://github.com/SSSD/sssd/pull/5222 which
has been fixed upstream.
https://patch-diff.githubusercontent.com/raw/SSSD/sssd/pull/5222.patch
-- System Information:
Debian Release: 10.4
APT prefers
Package: sssd
Version: 2.3.0-2
Severity: grave
Justification: renders package unusable
This locks me out of my systems.
$ sudo -l
[sudo] password for sam.morris@ad.domain.example:
Sorry, try again.
[sudo] password for sam.morris@ad.domain.example:
Sorry, try again.
[sudo
Thanks.
I am in the middle of fixing.
Apologies I didn't get a fix uploaded before you filed a bug.
Package: libpango-1.0-0
Version: 1.44.7-3
Followup-For: Bug #958017
Control: -1 severity minor
After upgrading libpangocairo-1.0-0 to the version in unstable,
pango-view gives some more useful messages:
(pango-view:303404): GLib-GObject-WARNING **: 13:40:03.869: specified class
size for type
Package: libpango-1.0-0
Version: 1.44.7-3
Severity: grave
Justification: renders package unusable
After upgrading libpango-1.0-0 from version 1.42.4-7~deb10u1 to version
1.44.7, gnome-terminal-server will no longer start. It crashes with:
#0 0x in ?? ()
#1 0x7fa7b804
Package: systemd
Followup-For: Bug #955541
Control: affects -1 + sssd
This also prevents logging in using Active Directory credentials with
sssd. This is because sssd synthesizes an AD user's user name with:
CONCAT(SAM-Account-Name, '@', DNS Domain Name)
This also applies to gro
.
Up to date information on MaraDNS’s security is available at
https://maradns.samiam.org/security.html
On Sat, Nov 2, 2019 at 6:54 AM Sam Trenholme wrote:
> Upstream here: Please close this bug.
>
> One can close this bug by removing the Python2 dependency.
>
> MaraDNS does not
control: tags -1 patch
> "peter" == peter green writes:
peter> Tags 944714 +patch Thanks.
peter> The easy fix here is to remove -Werror, in the long term of
peter> course migration to a non-deprecated type should be
peter> considered but that is IMO an issue for upstream not
Acknowledged.
DPL is taking up all my Debian time at the moment.
It's not the end of the world if moonshot-trust-router falls out of
testing, but hopefully I'll get to this before it happens.
It's almost certainly simple.
Santiago,
That is correct. Changing 'VERSION_ID=10' to 'VERSION_ID=10.1' in
/etc/os-release is what I am asking.
---
Respectfully,
Sam Doran
> On Nov 8, 2019, at 06:16, Santiago Vila wrote:
>
> Hi.
>
> Just to be sure: The proposed change would be
> "Michael" == Michael Biebl writes:
Michael> On Wed, 30 Oct 2019 13:22:14 + Ian Jackson
Michael> wrote:
>> The bulk of the bug is a discussion about the general approach to
>> allowing Debian users to choose between systemd and elogind (and,
>> therefore, allowing t
>>>>> "Mark" == Mark Hindley writes:
Mark> Sam, Since I cannot get a working and robust dpkg-divert
Mark> solution, I feel the need to revisit the validity of these
Mark> concerns.
I'd like to push back on the phrasing here.
What i'm hear
> "Thorsten" == Thorsten Glaser writes:
Thorsten> On Wed, 25 Sep 2019, Mark Hindley wrote:
>> libelogind0 can be coninstalled with libsystemd0. However, it is
>> fragile because the file that needs to be diverted out of the way
>> is libsystemd.so.0.26.0 (the actual library fi
>>>>> "Mark" == Mark Hindley writes:
Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
>> Foo-package depends on the latest libsystemd0. I'm running
>> unstable or testing. The latest libsystemd0 isn't building on m
s and
take a look at what is #if 0'd you can see the naming differences.
I don't know what would happen if you built a elogind that used systemd
naming. I don't know what the next hurtle would be.
--Sam
> "Mark" == Mark Hindley writes:
>> If we are going to use c/r/p libsystemd0, is there some way we
>> can limit the potential damage to people who have positively
>> indicated that they want to run a non-default init system? One
>> of the concerns is what happens if apt deci
nderstand that it's frustrating to have had this discussion
with systemd maintainers and then turn around and need to have it with a
release team member.
And I did try to read the systemd discussions. If you had clearly
articulated in that discussion why you needed c/r/p libsystemd0 at a
level deeper than "because it doesn't work the other way," then I'd be
pushing back on Julien harder.
--Sam
>>>>> "Adam" == Adam Borowski writes:
Adam> On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
>> I reached out to jcristau to talk about his block hint. Based on
>> our IRC discussion, it sounds like he was having trouble br
athetic.
So now you've got conflicting requirements coming from multiple
directions.
I really don't see a way forward besides getting enough of the right
parties involved to understand the issues and come up with a solution
that balances the trade offs across multiple packages.
I'm sorry that you've been placed in this position.
--Sam
Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939768
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the out
The release notes for PILlow 6.1
(https://pillow.readthedocs.io/en/stable/releasenotes/6.0.0.html#backwards-incompatible-changes)
indicate that Image.VERSION has been dropped in favour of using
Image.__version__. VERSION was fossilised at '1.1.7' 9 years ago to avoid
confusing legacy users of t
ed to
reload the config while dpkg was still writing it out?
sssd_pac crash: sssd_pac dies after about five minutes with the "The
last reference on a connection was dropped without closing the
connection. This is a bug in an application. [...] Most likely, the
application called unref() too many times and removed a reference
belonging to libdbus, since this is a shared connection." If this
persists after a reboot I'll file a separate bug for it.
--
Sam Morris
eplacements you are
thinking of?
I'm also having a bit of trouble trying to understand how the various
hook directories work (power.d, sleep.d, etc). If I install pm-utils
and use another mechanism like say systemctl suspend to suspend my
system, do the pm-utils hooks get called or not?
--Sam
en.
Again, feel free to ignore this message entirely if it does not move the
conversation forward.
I'm just seeing a stuck issue and proposing a way to try and unstick it.
--Sam
signature.asc
Description: PGP signature
4ff..c30a279 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+electrum (3.2.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * On startup print a warning that this version in insecure and then
+exit, Closes: #928518
+
+
+ -- Sam Hartman Mon, 06 May 2019
master accept a request
to remove the package?
--Sam
signature.asc
Description: PGP signature
control: severity -1 normal
Hi. I ran a number of other upgrades today of libvirtd from stretch to
buster and was not able to reproduce the problem in the environments I
thought would cause it.
I don't know what's up, but I don't think characterizing this as RC
given the data we have is correct.
When I marked the bug RC, I thought it was happening all the time; I
then went to reproduce yet again in a controlled environment to be more
in a position to test a fix.
That's when I discovered things are more complex.
Obviously if this is a fringe situation, then it shouldn't be RC.
>>>>> "Guido" == Guido Günther writes:
Guido> Hi,
Guido> On Mon, Apr 15, 2019 at 02:38:27PM -0400, Sam Hartman wrote:
>> control: severity -1 serious
>>
>> justification: libvirtd upgrades from stretch to buster break
>
Guido let me know if you need any help or prod me on IRC if I'm needed.
Will certainly test the result, but if you get stuck would be happy to
spend time on this.
1 - 100 of 922 matches
Mail list logo
