me to follow up on these rc bugs.
I am closing #1063135, because we will not move forward with a rename to
libselinux1t64. The package has been removed from experimental
meanwhile, so this is fully done.
We have addressed the package upgrade by not moving from libselinux1 to
libselinux1t64, but
P behaviour in a number of ways which I think will cause people
> > problems when they upgrade to trixie, this is one of them.
>
> We do have Release Notes to (also) document important changes like this.
Ofc. However I'm concerned for people that skip reading that kind of
pap
gt; Context: dhcpcd-base has taken over DHCP duties from isc-dhcp-client in
> > ustable via priority override at Martin's request. This changes a Debian
> > installs DHCP behaviour in a number of ways which I think will cause people
> > problems when they upgrade to trixie
HCP behaviour in a number of ways which I think will cause people
problems when they upgrade to trixie, this is one of them.
We do have Release Notes to (also) document important changes like this.
Original report:
dhcpcd-base does not send the system's hostname by default as
isc-d
ber of ways which I think will cause people
problems when they upgrade to trixie, this is one of them.
Original report:
> dhcpcd-base does not send the system's hostname by default as
> isc-dhcp-client used to due to /etc/dhcpcd.conf having the `hostname`
> option commented out.
>
&
On 9/9/24 17:23, Andres Salomon wrote:
On 9/9/24 17:16, Sylvestre Ledru wrote:
Le lundi 9 septembre 2024 à 23:12, Andres Salomon
a écrit :
>
>
> We're currently using clang-16 in sid because it's also in
bookworm, and
> it's easier to use the same compiler for both distributions.
>
Package: dhcpcd-base
Version: 9.4.1-24~deb12u2
Severity: serious
Justification: file loss during upgrade
X-Debbugs-Cc: debian-release@lists.debian.org
User: helm...@debian.org
Usertags: dep17p1
Unfortunately, the stable update of dhcpcd5 introduced a regression
relevant to upgrades from bullseye
Package: release-notes
Hi Harald,
On 28-04-2023 16:38, Harald Dunkel wrote:
AFAIU the sssd cache becomes invalid on the upgrade to Bookworm due to a
new format. If you are using the company account to login on your laptop
you might get locked out at upgrade time. This affects FreeIPA and maybe
Hi folks,
AFAIU the sssd cache becomes invalid on the upgrade to Bookworm due to a
new format. If you are using the company account to login on your laptop
you might get locked out at upgrade time. This affects FreeIPA and maybe
AD accounts.
I haven't seen it mentioned on
https://www.debia
Dear DSA,
As is custom for the Release Team, I'm asking you what your plans are
with respect to testing upgrading DSA maintained machines to bookworm.
If my information is correct, in the past you'd first upgrade a non
critical machine to see if there's anything broken in bookwor
Dear DSA,
As is custom for the Release Team, I'm asking you what your plans are
with respect to testing upgrading DSA maintained machines to bookworm.
If my information is correct, in the past you'd first upgrade a non
critical machine to see if there's anything broken in bookwor
affected, as well as the currently supported
versions 3.2.1 and 3.3.2. Integrators and users are advised to upgrade to
3.2.2 and 3.3.3 respectively.
Important: The mitigation against these vulnerabilities depends on the
installation of the latest ModSecurity version (v2.9.6/v3.0.8) or an updated
versi
Hi Paul, and others,
On Mon, Sep 12, 2022 at 10:21:12PM +0200, Paul Gevers wrote:
> Hi,
>
> On 02-09-2022 14:35, Ervin Hegedüs wrote:
> > *We need to know if we could add this patch to the existing packages
> > (3.3 in both Debian 10 and Debian 11) without CVE or not.*
>
> Well, Debian 10 got it
Hi,
Sorry for the delay in responding. This list is very high volume (it
receives bug reports too) and plain messages sometimes slip through.
On 02-09-2022 14:35, Ervin Hegedüs wrote:
*We need to know if we could add this patch to the existing packages
(3.3 in both Debian 10 and Debian 11) wi
Dear Debian Release team!
(Cc-d Christian Follini, co-leader of CRS team - please also Cc him to
answers)
Couple of months ago, the CRS team got an opportunity from a big IT
company: a Bug Bounty program for CoreRuleSet and ModSecurity.
The program produces tons of reactions from the elite hack
Hello, good afternoon.
Upgraded Debian 9 to Debian 10 on an HP DL380G5 server but I have problems
with the smart arrary P400, it does not detect it with kernel 4.19, if I
load it on older kernel 4.09 there is no problem. Can you give me a hand ?.
Thanks.
Hello, good afternoon.
Upgraded Debian 9 to Debian 10 on an HP DL380G5 server but I have problems
with the smart arrary P400, it does not detect it with kernel 4.19, if I
load it on older kernel 4.09 there is no problem. Can you give me a hand ?.
Thanks.
Your message dated Thu, 8 Jul 2021 16:14:44 +0200
with message-id
and subject line Re: Bug#990515: release.debian.org: buster->bullseye upgrade
issue: sshfs is not upgraded due to fuse/fuse3
has caused the Debian Bug report #990515,
regarding release.debian.org: buster->bullseye upgrade
On 01/07/2021 12.04, Andreas Beckmann wrote:
I'm just trying the attached patch which seems to solve the issue for
the kde metapackages with --install-recommends
kdeconnect is the one depending on sshfs, so it's a good candidate to
ensure we get fuse3 installed.
I've filed bugs against sshfs,
late for glibc changes.
I think we really want this. I *think* I ran into exactly this issue two
days ago when I upgraded my NAS. It's really scary to notice that you
can't log into your system and your only connection is the current one
running the upgrade. In my case, it was asking questio
Control: reassign -1 libc6 2.31-12
Control: affects -1 openssh-server
On Sat, Jul 03, 2021 at 11:36:49AM +0200, Olaf van der Spek wrote:
> Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek :
> > So I think it's not accepting new connections from the start of the
> > upgra
On 01/07/2021 10.38, Paul Gevers wrote:
Hi,
On 01-07-2021 10:03, Michael Biebl wrote:
Related issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918984
Right, I forgot about that bug. The issue and "solution" is documented
in the release notes. @Andreas, can you confirm that the text th
Hi,
On 01-07-2021 10:03, Michael Biebl wrote:
> Related issue:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918984
Right, I forgot about that bug. The issue and "solution" is documented
in the release notes. @Andreas, can you confirm that the text there is
sufficient for the issues you exp
Am 01.07.21 um 09:32 schrieb Paul Gevers:
Hi Andreas, Laszlo,
On 01-07-2021 08:27, Andreas Beckmann wrote:
Package: release.debian.org
Severity: normal
let's start a discussion here and once we found a package to upgrade,
turn this into an unblock request.
And let's add the fuse
Hi Andreas, Laszlo,
On 01-07-2021 08:27, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
>
> let's start a discussion here and once we found a package to upgrade,
> turn this into an unblock request.
And let's add the fuse and fuse3 mai
Package: release.debian.org
Severity: normal
let's start a discussion here and once we found a package to upgrade,
turn this into an unblock request.
sshfs is sometimes kept at the buster version because of some dependency
mess of fuse/fuse3.
This usually shows up in large metapackages
On 30/06/2021 21.58, Paul Gevers wrote:
fix could be pushed to buster-updates s.t. it is available for the
oldstable-upgrade before the dist-upgrade, at least on sane systems.
We'll have to discuss this with the SRM, hence I also wanted to know
from you if you experienced worse cases
Hi,
On 30-06-2021 21:53, Andreas Beckmann wrote:
> On 30/06/2021 21.38, Paul Gevers wrote:
> In case there is no further buster point release before bullseye, the
> fix could be pushed to buster-updates s.t. it is available for the
> oldstable-upgrade before the dist-upgrade, at l
On 30/06/2021 21.38, Paul Gevers wrote:
I prefer to update libgc in buster and document this behavior in the
release notes. As far as I'm aware, this is a "cosmetic" issue in that
after the upgrade where packages are hold back, a second upgrade fixes
the issue. If that view of t
As far as I'm aware, this is a "cosmetic" issue in that
after the upgrade where packages are hold back, a second upgrade fixes
the issue. If that view of the situation is incomplete, please enlighten
us. If that view is correct, lets fix bug 988963.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Your message dated Sun, 27 Jun 2021 16:13:28 +0200
with message-id
and subject line Re: Bug#989597: release.debian.org: upgrade issue:
non-coinstallability of libgdal20 and libgdal28
has caused the Debian Bug report #989597,
regarding release.debian.org: upgrade issue: non-coinstallability of
tion data included in gdal.
>
> Other than that I don't know. You'd have to grep through the sources to
> find the functions using those files, and then search through reverse
> dependencies for use of those functions.
>
> > I.e. on a partial upgrade. (Could som
g those files, and then search through reverse
dependencies for use of those functions.
> I.e. on a partial upgrade. (Could someone run autopkgtests in
> buster with the proposed gdal-data?)
Many of the gdal rdeps don't have autopkgtests, and the most prominents
ones don't.
not aware of any packages
that use gdal in the maintainer scripts that would be using the old gdal
on their removal. So there shouldn't be any actual expected breakage.
Do you have some ideas what could break by installing gdal-data 3.x in
buster? I.e. on a partial upgrade. (Could someone r
Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.
To avoid exactly this problem, postgresql-common is maintaining a l
Re: Andreas Beckmann
> > modulo the problem I ran into. (I still have to retry it.)
>
> Didn't see this on my side.
> Your --force-depends probably affected more than just libgdal20.
Found the problem, I had not restarted postgresql-11 after the
upgrade, so it was still li
On 6/15/21 8:23 AM, Andreas Beckmann wrote:
> On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
>> From the many other packages I haven't seen other issues other than the
>> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>>
>> I really nee
has been identified is the need for
>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
>>> present.
>>
>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
>> attached, no bug filed, yet). The only solution I could find
On 17/06/2021 15.26, Christoph Berg wrote:
Re: Andreas Beckmann
* how do I get some tables using the postgis extension into the database to
sudo -u postgres psql -vON_ERROR_STOP=1 <
Thanks!
Once gdal is fixed,
I used my patched packages (will try to put them somewhere public tonight)
p
0F03FF03FF03F
> * how do I correctly migrate the database (with postgis stuff) from 11 to 13
As said in
OK, I tried it as well.
buster# apt-get install postgresql-11-postgis-2.5
# in a minimal chroot, pulls in postgresql-11
# I haven't done anything with postgres, so it should be essentially
empty (so only default users, tables, data exist (if any))
buster# apt-get dist-upgrade
# to bul
> So there seems to be some additional incompatibility in libsfcgal1 -> libc6.
> >...
>
> It's already in the package dependencies:
>
> Package: libsfcgal1
> Version: 1.3.9-2
> Depends: ..., libc6 (>= 2.29),...
>
> This won't work unless you upgrade libc6
the package dependencies:
Package: libsfcgal1
Version: 1.3.9-2
Depends: ..., libc6 (>= 2.29),...
This won't work unless you upgrade libc6 to the bullseye version.
> Christoph
cu
Adrian
Re: Sebastiaan Couwenberg
> Options for a working postgis database after distribution upgrade
> include recreating the databases by running your ETL process on the new
> cluster after upgrade, or using symlink hacks to workaround the
> version-in-extension-filename issue
On 6/15/21 3:55 PM, Sebastian Ramacher wrote:
> On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
>> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
>>> If neither you as maintainer nor upstream care about upgrade without
>>> data loss, I don't think postgis is sui
On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> > If neither you as maintainer nor upstream care about upgrade without
> > data loss, I don't think postgis is suitable to be included in a stable
> > release. Best o
Followup-For: Bug #989599
Hi,
a possible solution would be to rename libgc1 to libgc1a (or similar).
To avoid needing a full transition, I've added a transitional package
libgc1. After rebuilding guile-2.2 and guile-3.0 against libgc1a
upgrades start to go smooth - libgc1c2 from buster gets remov
On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> If neither you as maintainer nor upstream care about upgrade without
> data loss, I don't think postgis is suitable to be included in a stable
> release. Best option moving forward is to get postgis and its reverse
> dependen
e:
> >>>> What actual problems do are solved by making them co-installable?
> >>>>
> >>>> So far the only actualy problem that has been identified is the need for
> >>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is n
On 6/15/21 8:23 AM, Andreas Beckmann wrote:
> On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
>> From the many other packages I haven't seen other issues other than the
>> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
>>
>> I really nee
On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:
From the many other packages I haven't seen other issues other than the
partial upgrade with monteverdi which is fixed with Breaks/Replaces.
I really need more concrete cases to justify changes to gdal that I
don't like but wi
-installable?
>>>>
>>>> So far the only actualy problem that has been identified is the need for
>>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
>>>> present.
>>>
>>> apt currently fails to find an upgrade p
aly problem that has been identified is the need for
> >> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
> >> present.
> >
> > apt currently fails to find an upgrade path for libmrpt-dev (logfile
> > attached, no bug filed, yet). The o
On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>> What actual problems do are solved by making them co-installable?
>>
>> So far the only actualy problem that has been identified is the need for
>> `apt full-upgrade` twi
On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
What actual problems do are solved by making them co-installable?
So far the only actualy problem that has been identified is the need for
`apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
present.
apt currently fails to
ackage.
postgis by itself is not interesting, its only contains commandline
tools. postgresql-11-postgis-2.5 is the package which contains the
postgresql extension. That (also) get removed during the `apt upgrade`
from buster to bullseye.
I don't particularly care about having libgdal20
ieved libgdal20/libgdal28 co-installability ;-)
More tests ongoing.
This is how apt resolves the postgis upgrade - nothing has to be
removed any more:
Starting 2 pkgProblemResolver with broken count: 0
Done
The following packages were automatically installed and are no longer req
On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote:
> On 13/06/2021 22.44, Sebastian Ramacher wrote:
> > My goal is to make libgdal20 and libgdal28 co-installable. Adding those
> > Breaks is not enough and is step into the wrong direction.
>
> Thanks for making that clear. I'll think again about
On 13/06/2021 22.44, Sebastian Ramacher wrote:
My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not enough and is step into the wrong direction.
Thanks for making that clear. I'll think again about libogdi ...
@Seb: could you upload the gdal3-data patch to expe
t;>>> #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades
> >>>> from buster, that seems like a reasonable change.
> >>>
> >>> See attached patch. Especially for its very verbose changelog entry ;-)
> >>
> >> A build wit
ch. Especially for its very verbose changelog entry ;-)
>>
>> A build with the Breaks is running as we speak, if that resolves the
>> montiverdi case I'll upload it to unstable, unless you expect more changes.
>
> Please rename the binary package and follow the spirit of Po
On 2021-06-13 11:30:47 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> > On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
> >> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked g
On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> > On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> >>> I have unblocked gdal.
> >>
> >> Thanks, libgdal (3.2.2-1) will need to be unbloc
On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
I have unblocked gdal.
>>>
>>> Thanks, libgdal (3.2.2-1) will need to be unblocked as w
On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
>>> I have unblocked gdal.
>>
>> Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>
> libgdal-grass ?
Obviously, yes.
>> hand in
On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> > On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> > > I have unblocked gdal.
> >
> > Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>
> libgdal-grass ?
>
> > hand in
On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
I have unblocked gdal.
Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
libgdal-grass ?
hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
version of gda
On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked gdal.
Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
version of gdal to build successfully.
> Please go ahead with an upload adding a gdal
e:
> >>>> gdal can rename gdal-data to gdal3-data, build with
> >>>> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
> >>>> Thus libgdal20 + gdal-data from buster should be co-installable with
> >>>> libgdal28 + gdal3-data fro
gt;>> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
>>>> Thus libgdal20 + gdal-data from buster should be co-installable with
>>>> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
>>>>
>>>> A patch doing this
gdal20.
> >> Thus libgdal20 + gdal-data from buster should be co-installable with
> >> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
> >>
> >> A patch doing this is attached, I'm now testing the upgrade paths
> >> (along
ble with
>> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
>>
>> A patch doing this is attached, I'm now testing the upgrade paths
>> (along the introduction of the libhdf5*-103 metapackages).
>
> If the gdal-data issue is solved, the n
On 08/06/2021 11.56, Andreas Beckmann wrote:
gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if
On 08/06/2021 12.22, Sebastiaan Couwenberg wrote:
Please spend your time on other more deserving packages.
I'm not caring that much about postgis but about getting clean upgrade
paths if hdf5 and or gdal are involved because of the (transitive)
non-co-installability of libhdf5*-103/li
ith
> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
> Thus libgdal20 + gdal-data from buster should be co-installable with
> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
>
> A patch doing this is attached, I'm now testing the upgrade pat
Followup-For: Bug #989599
Let's start the debian-release@ discussion here and decide which package
needs to get unblocked later ;-) We can turn this into an unblock bug
then.
This issue shows up e.g. on all (at least most) upgrade paths where 'cron'
was installed.
Andreas
llable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
A patch doing this is attached, I'm now testing the upgrade paths
(along the introduction of the libhdf5*-103 metapackages).
A good gdal bug to reuse would be #986975
Updating gdal may be a bit more tricky, b
Hi,
On 2021-02-25 10:25, Paul Gevers wrote:
> Dear DSA,
>
> As is custom for the Release Team, I'm asking you what your plans are
> with respect to testing upgrading DSA maintained machines to bullseye.
>
> If my information is correct, in the past you'd first upgr
On Thu, 25 Feb 2021, Paul Gevers wrote:
> As is custom for the Release Team, I'm asking you what your plans are
> with respect to testing upgrading DSA maintained machines to bullseye.
>
> If my information is correct, in the past you'd first upgrade a non
> critical
Dear DSA,
As is custom for the Release Team, I'm asking you what your plans are
with respect to testing upgrading DSA maintained machines to bullseye.
If my information is correct, in the past you'd first upgrade a non
critical machine to see if there's anything broken in bullsey
On Sun, 14 Feb 2021 at 20:06:00 +, Phil Morrell wrote:
> On Sun, Feb 14, 2021 at 04:58:35PM +, Simon McVittie wrote:
> > I wanted to provide some signal boost for this and related upgrade issues.
> > Ryan Pavlik, one of my colleagues at Collabora, ran into a similar upgr
On Sun, Feb 14, 2021 at 04:58:35PM +, Simon McVittie wrote:
> On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote:
> > [The release team are] pretty concerned about a couple of known RC bugs
> > which need the proper attention of people familiar with upgrade paths
> >
On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote:
> [The release team are] pretty concerned about a couple of known RC bugs
> which need the proper attention of people familiar with upgrade paths
> as there's potential to leave upgrading systems unbootable and/or
> with
Your message dated Thu, 02 Jul 2020 21:01:00 +0100
with message-id
<610b56fda617de0e2949a3300597c340a9e9cfcf.ca...@adam-barratt.org.uk>
and subject line Re: Bug#913674: Preparing p-u upload
has caused the Debian Bug report #913674,
regarding release.debian.org: Regression: Recent upgr
Package: libgcc1
Version: 1:10-20200202-1
Severity: serious
Upgrading libgcc1 to version >= 10 on a system breaks gcc-7, gcc-8 and
gcc-9 when using the gold linker, as gcc passes the wrong path to the
libgcc_s.so.1 library. All architectures are affected, example on amd64,
starting from a bullseye
uot; state.
Output from retrying the configuration of the package:
root@matrix:/usr/share/doc/cyrus-common# dpkg --configure --pending
Setting up cyrus-common (3.0.8-6+deb10u1) ...
Creating/updating cyrus user account...
The user `cyrus' is already a member of `sasl'.
/usr/lib/cyrus/bin/upgrade
la 14. syysk. 2019 klo 16.57 Adam D. Barratt
(a...@adam-barratt.org.uk) kirjoitti:
>
> On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote:
> > To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is
> > still open for Buster and Stretch.
>
> Is there a likely ETA for when this migh
On Fri, 2019-09-13 at 21:10 +0300, Otto Kekäläinen wrote:
> To clarify, 10.3.18 has been uploaded to Debian unstable. Issue is
> still open for Buster and Stretch.
Is there a likely ETA for when this might be resolvable?
If you could prepare (preferably targeted) updates via the usual p-u
path th
Copying to release team:
On Thu 16 May 2019 at 05:03PM -07, Sean Whitton wrote:
> The version of unattended-upgrades in stretch defaulted to not upgrading
> the stable suite. It would install only security updates.
>
> The version of unattended-upgrades in buster upgrades both the stable
> suite
Your message dated Mon, 8 Apr 2019 17:36:12 +0200
with message-id <20190408153611.rxwx3uym5cg2k...@debian.org>
and subject line Re: release.debian.org: Upgrade strategy for apache2 in Buster
has caused the Debian Bug report #926303,
regarding release.debian.org: Upgrade strategy for apac
Package: release.debian.org
Severity: normal
Hi all,
New Apache 2.4.39 fixes many bugs (including 5 CVEs [1]) with only 2
minor new features. Do you think it is a good idea to upgrade Apache
version in Buster or do you prefer a 2.4.38 with 2.4.39 fixes (means
2.4.39 without ~2 commits) or only
Package: glx-diversions
Version: 0.8.8~deb9u1
Severity: serious
Justification: regression
Hi
glx-diversions package update fails from the version in stretch (0.8.3~deb9u1)
to stretch-proposed-updates (0.8.8~deb9u1). The severity is actually a bit
overrated, package can be confgured afterwards, bu
Processing control commands:
> reassign -1 release.debian.org
Bug #916299 [postgresql-11] postgresql-11: starts with error after upgrade from
stretch to buster
Bug reassigned from package 'postgresql-11' to 'release.debian.org'.
No longer marked as found in versio
On Thu, 2018-11-15 at 12:56 -0500, Eric Dorland wrote:
> Sorry for the delay, I'm happy to prepare a p-u upload this weekend.
Any update on that?
Regards,
Adam
Sorry for the delay, I'm happy to prepare a p-u upload this weekend.
--
Eric Dorland
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
How do I unsubscribe?
On November 13, 2018 6:10:23 PM EST, Hilko Bengen wrote:
>* Adam D. Barratt:
>
>> On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
>>>
>>> A few weeks ago I reported that a security patch in
>>> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices
>(#910786,
>
* Adam D. Barratt:
> On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
>>
>> A few weeks ago I reported that a security patch in
>> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
>> severity serious). Unfortunately, this did not prevent opensc from
>> being included in
Processing control commands:
> severity -1 normal
Bug #913674 [release.debian.org] release.debian.org: Regression: Recent upgrade
of opensc breaks Yubikey NEO support
Severity set to 'normal' from 'grave'
--
913674: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913
Control: severity -1 normal
On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
> Package: release.debian.org
> Severity: grave
RC bugs in psuedo-packages / teams generally don't make much sense. (On
the whole, anything > normal against release.d.o is likely to be
wrong.)
> Tags: stretch
>
>
Package: release.debian.org
Severity: grave
Tags: stretch
A few weeks ago I reported that a security patch in
opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
severity serious). Unfortunately, this did not prevent opensc from being
included in the recent stretch point release.
1 - 100 of 740 matches
Mail list logo
