Uploading linux (6.0.10-2)
Hi I would like to upload linux version 6.0.10-2 to unstable later today with one single change: * [x86] drm/i915: fix TLB invalidation for Gen12 video and compute engines (CVE-2022-4139) For that no ABI change required. It will soon be followed by 6.0.11-1 or later though. Regards, Salvatore signature.asc Description: PGP signature
Bug#1025215: transition: qtermwidget
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: LXQt Packaging Team , Tom
Jampen
This transition is for qtermwidget soversion changing from 0 to 1. The
following are reverse dependencies affected by this transition:
* qterminal: new version has been uploaded to experimental
* texstudio: binNMU
Ben file:
title = "qtermwidget";
is_affected = .depends ~ "libqtermwidget5-0" | .depends ~ "libqtermwidget5-1";
is_good = .depends ~ "libqtermwidget5-1";
is_bad = .depends ~ "libqtermwidget5-0";
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1025212: transition: libfm-qt
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
This transition is for libfm-qt soversion changing from 11 to 12. All
affected packages listed in [0] have been uploaded to experimental.
Except mips64el, mipsel, ppc64el, all other architectures can be built
successful.
[0] https://release.debian.org/transitions/html/auto-libfm-qt.html
Ben file:
title = "libfm-qt";
is_affected = .depends ~ "libfm-qt11" | .depends ~ "libfm-qt12";
is_good = .depends ~ "libfm-qt12";
is_bad = .depends ~ "libfm-qt11";
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1024756: marked as done (transition: libktorrent)
Your message dated Wed, 30 Nov 2022 23:29:46 +0100 with message-id and subject line Re: Bug#1024756: transition: libktorrent has caused the Debian Bug report #1024756, regarding transition: libktorrent to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1024756: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024756 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: Debian Qt/KDE Maintainers Dear Release Team, I’d like to request a transition slot for libktorrent. It has 2 reverse dependencies: - kget - ktorrent Both rebuild successfully with the new version of the library. I’ve uploaded libktorrent 22.08.3-3 with the new ABI to experimental and it builds successfully on the same architectures as previously. [0] Ben file: title = "libktorrent"; is_affected = .depends ~ "libkf5torrent6abi2" | .depends ~ "libkf5torrent6abi3"; is_good = .depends ~ "libkf5torrent6abi3"; is_bad = .depends ~ "libkf5torrent6abi2"; [0] https://buildd.debian.org/status/package.php?p=libktorrent=experimental Thanks, -- Aurélien --- End Message --- --- Begin Message --- On 2022-11-25 07:21:44 +0100, Aurélien COUDERC wrote: > Hi Sebastian, > > Le 24 novembre 2022 21:23:47 GMT+01:00, Sebastian Ramacher > a écrit : > >Control: tags -1 confirmed > > >On 2022-11-24 11:05:08 +0100, Aurélien COUDERC wrote: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> X-Debbugs-Cc: Debian Qt/KDE Maintainers > >> > >> Dear Release Team, > >> > >> I’d like to request a transition slot for libktorrent. > >> > >> It has 2 reverse dependencies: > >> - kget > >> - ktorrent > > > >Please go ahead. > > > libktorrent is uploaded to unstable and built on all relevant archs. > > Could you please binNMU kget and ktorrent ? Done and the old binaries got removed from testing. Closing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1023495: transition: ruby3.1
On 2022-11-30 09:14:55 -0300, Antonio Terceiro wrote: > On Wed, Nov 23, 2022 at 05:35:18PM +0100, Sebastian Ramacher wrote: > > Hi Antonio > > > > On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > > > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > > > Hi Lucas, > > > > > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > > > After discussing with Antonio, since our deadline to finish the > > > > > > transition is approaching, we decided to already enable ruby3.1 as > > > > > > the > > > > > > default and remove ruby3.0 in a single step. > > > > > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of > > > > > the > > > > > default a forward rebuild, while removal is a backward rebuild (I > > > > > mean in > > > > > the dependency tree)? If that's true, I think doing it in two steps is > > > > > easier to manage, as packages can then migrate on their own and don't > > > > > need a > > > > > lock step migration. > > > > > > > > That's correct. I'd prefer to handle this with two trackers. > > > > > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > > > start the transition in unstable? > > > > I'd like protobuf to migrate first which is currently doing its own > > transition. Afer that, we can go ahead with the switch to 3.1 as > > default. > > protobuf migrate a few days ago, so I just uploaded ruby-defaults. > Please binNMU these packages: > > epic5 > graphviz > ignition-math > kamailio > klayout > kross-interpreters > libprelude > marisa > ngraph-gtk > notmuch > obexftp > redland-bindings > subtle > subversion > vim-command-t > weechat > xapian-bindings binNMUs scheduled Cheers -- Sebastian Ramacher
Bug#1025205: bullseye-pu: package mplayer/2:1.4+ds1-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
This updates fixes various minor crashes in mplayer, which
don't warrant a DSA by itself. I've run the PoCs against
the updated build where applicable and also tested various
random media files.
Note this isn't fixed in unstable, since mplayer FTBFSes
with ffmpeg 5.0 and won't be in bookworm (#1005899).
Cheers,
Moritz
diff -Nru mplayer-1.4+ds1/debian/changelog mplayer-1.4+ds1/debian/changelog
--- mplayer-1.4+ds1/debian/changelog2020-10-15 00:13:44.0 +0200
+++ mplayer-1.4+ds1/debian/changelog2022-11-28 21:31:43.0 +0100
@@ -1,3 +1,19 @@
+mplayer (2:1.4+ds1-1+deb11u1) bullseye; urgency=medium
+
+ * Backport the following commits:
+d19ea1ce173e95c31b0e8acbe471ea26c292be2b (CVE-2022-38850)
+58db9292a414ebf13a2cacdb3ffa967fb9036935 (CVE-2022-38851)
+2f6e69e59e2614acdde5505b049c48f80a3d0eb7 (CVE-2022-38855)
+92e0d0b1a04dfdd4ac741e0d07005e3ece2c92ca (CVE-2022-38858)
+62fe0c63cf4fba91efd29bbc85309280e1a99a47 (CVE-2022-38860)
+2622e7fbe3605a2f3b4f74900197fefeedc0d2e1 (CVE-2022-38861)
+b5e745b4bfab2835103a060094fae3c6cc1ba17d (CVE-2022-38863)
+36546389ef9fb6b0e0540c5c3f212534c34b0e94 (CVE-2022-38864)
+33d9295663c37a37216633d7e3f07e7155da6144 (CVE-2022-38865)
+373517da3bb5781726565eb3114a2697b13f00f2 (CVE-2022-38866)
+
+ -- Moritz Mühlenhoff Mon, 28 Nov 2022 21:31:43 +0100
+
mplayer (2:1.4+ds1-1) unstable; urgency=medium
* Team upload
diff -Nru
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
---
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
1970-01-01 01:00:00.0 +0100
+++
mplayer-1.4+ds1/debian/patches/CVE-2022-38850_CVE-2022-38851_CVE-2022-38855_CVE-2022-38858_CVE-2022-38860_CVE-2022-38861_CVE-2022-38863_CVE-2022-38864_CVE-2022-38865_CVE-2022-38866.patch
2022-11-28 21:31:07.0 +0100
@@ -0,0 +1,235 @@
+Backports of the following commits:
+
+d19ea1ce173e95c31b0e8acbe471ea26c292be2b (CVE-2022-38850)
+[PATCH] vd.c: sanity-check aspect adjustment
+
+58db9292a414ebf13a2cacdb3ffa967fb9036935 (CVE-2022-38851)
+PATCH] asfheader.c: Fix CHECKDEC macro.
+
+2f6e69e59e2614acdde5505b049c48f80a3d0eb7 (CVE-2022-38855)
+[PATCH] demux_mov.c: Add bounds checks to debug prints.
+
+92e0d0b1a04dfdd4ac741e0d07005e3ece2c92ca (CVE-2022-38858)
+[PATCH] demux_mov.c: robustness fixes.
+
+62fe0c63cf4fba91efd29bbc85309280e1a99a47 (CVE-2022-38860)
+[PATCH] demux_avi.c: check that sh->wf exists before using it.
+
+2622e7fbe3605a2f3b4f74900197fefeedc0d2e1 (CVE-2022-38861)
+[PATCH] mp_image.c: fix allocation size for formats with odd width.
+
+b5e745b4bfab2835103a060094fae3c6cc1ba17d (CVE-2022-38863)
+[PATCH] mpeg_hdr.c: Allocate 0xff initialized padding.
+
+36546389ef9fb6b0e0540c5c3f212534c34b0e94 (CVE-2022-38864)
+[PATCH] mpeg_hdr.c: Fix unescape code.
+
+33d9295663c37a37216633d7e3f07e7155da6144 (CVE-2022-38865)
+[PATCH] demux_avi.c: Fixup invalid audio block size.
+
+373517da3bb5781726565eb3114a2697b13f00f2 (CVE-2022-38866)
+[PATCH] aviheader.c: Fix allocation size for vprp
+
+
+--- mplayer-1.4+ds1.orig/libmpcodecs/mp_image.c
mplayer-1.4+ds1/libmpcodecs/mp_image.c
+@@ -51,8 +51,12 @@ void mp_image_alloc_planes(mp_image_t *m
+ }
+ mpi->planes[0]=av_malloc(mpi->bpp*mpi->width*(mpi->height+2)/8+
+ mpi->chroma_width*mpi->chroma_height);
+- } else
+-mpi->planes[0]=av_malloc(mpi->bpp*mpi->width*(mpi->height+2)/8);
++ } else {
++// for odd width round up to be on the safe side,
++// required in particular for planar formats
++int alloc_w = mpi->width + (mpi->width & 1);
++mpi->planes[0]=av_malloc(mpi->bpp*alloc_w*(mpi->height+2)/8);
++ }
+ if (mpi->flags_IMGFLAG_PLANAR) {
+ int bpp = IMGFMT_IS_YUVP16(mpi->imgfmt)? 2 : 1;
+ // YV12/I420/YVU9/IF09. feel free to add other planar formats here...
+--- mplayer-1.4+ds1.orig/libmpcodecs/vd.c
mplayer-1.4+ds1/libmpcodecs/vd.c
+@@ -332,7 +332,7 @@ int mpcodecs_config_vo(sh_video_t *sh, i
+ screen_size_y = screen_size_xy * sh->disp_h / sh->disp_w;
+ }
+ }
+-if (sh->aspect >= 0.01) {
++if (sh->aspect >= 0.01 && sh->aspect <= 100) {
+ int w;
+ mp_msg(MSGT_CPLAYER, MSGL_INFO, MSGTR_MovieAspectIsSet,
+sh->aspect);
+@@ -350,6 +350,8 @@ int mpcodecs_config_vo(sh_video_t *sh, i
+ } else {
+ mp_msg(MSGT_CPLAYER, MSGL_INFO, MSGTR_MovieAspectUndefined);
+
Bug#1025204: bullseye-pu: package speech-dispatcher/0.10.2-2+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hello, I'd like to have version 0.10.2-2+deb11u2 of speech-dispatcher uploaded to bullseye. [ Reason ] As reported on https://github.com/espeak-ng/espeak-ng/issues/1554 there is a longstanding buffer overflow issue in espeak-ng. It appears to users as artifacts in the speech that makes it sometimes less inteligible. But since they are due to a buffer overflow, the consequences could actually be way worse, notably since in the context of a screen reader using espeak-ng as speech synthesis, the data produced in the buffer comes from e.g. whatever webpage that the user is browsing, thus potential for security issues. This is not a regression from oldstable, since the bug has basically always been there. [ Impact ] If it is no included, users will still hear artifacts, and would also potentially be exposed to security issues due to the buffer overflows. [ Tests ] We made manual tests that confirmed that the change fixes the issue. We also confirmed the buffer overflow in espeak-ng's valgrind/asan CI. [ Risks ] The change is very trivial. It makes the speech synthesis processing a bit more expensive, but that will be very lightweight. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] The patch simply lowers the audio buffer size from 3s to 300ms. 3s was originally chosen so that large chunks of audio are processed at a time, but this is what is making espeak-ng overflow its synthesis buffers. The exact overflows should ideally be fixed in espeak-ng of course, but apparently this will be very involved, and it is way simpler to just make speech-dispatcher not request so large buffers. espeak-ng itself defaults to 60ms, and on Windows NVDA uses 300ms and does not suffer from buffer overflows. In practice, the overflows that we observed in https://github.com/espeak-ng/espeak-ng/issues/1554 happens with buffer around 900ms. 300ms seems a fairly safe value while being not too small so as to process not-so-small chunks of audio at a time. Samuel diff --git a/debian/changelog b/debian/changelog index 6fea892..b6120a2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +speech-dispatcher (0.10.2-2+deb11u2) bullseye; urgency=medium + + * patches/buffer_size: Reduce espeak buffer size to avoid synth artifacts. + + -- Samuel Thibault Wed, 30 Nov 2022 21:10:17 +0100 + speech-dispatcher (0.10.2-2+deb11u1) bullseye; urgency=medium * patches/generic-set-voice-name: Fix setting voice name for the generic diff --git a/debian/patches/buffer_size b/debian/patches/buffer_size new file mode 100644 index 000..2b13443 --- /dev/null +++ b/debian/patches/buffer_size @@ -0,0 +1,35 @@ +commit be4c3585ead45716b8f49300b50c30fdb6eee266 +Author: Alexander Epaneshnikov +Date: Thu Nov 24 01:41:40 2022 +0300 + +espeak: set buffer size to 300 + +this fixes #793 +ref for buffer size: https://github.com/nvaccess/nvda/blob/a6fb2392083b5fa1bae926102135ad452746ad3c/source/synthDrivers/_espeak.py#L338 + +diff --git a/config/modules/espeak-ng.conf b/config/modules/espeak-ng.conf +index d02704e9..9677bc99 100644 +--- a/config/modules/espeak-ng.conf b/config/modules/espeak-ng.conf +@@ -41,7 +41,7 @@ EspeakMaxRate 449 + # -- Internal parameters -- + + # Number of ms of audio returned by the espeak callback function. +-EspeakAudioChunkSize 3000 ++EspeakAudioChunkSize 300 + + # Maximum number of samples to buffer in playback queue. + EspeakAudioQueueMaxSize 441000 +diff --git a/config/modules/espeak.conf b/config/modules/espeak.conf +index 3abc422b..cbd453b7 100644 +--- a/config/modules/espeak.conf b/config/modules/espeak.conf +@@ -41,7 +41,7 @@ EspeakMaxRate 449 + # -- Internal parameters -- + + # Number of ms of audio returned by the espeak callback function. +-EspeakAudioChunkSize 3000 ++EspeakAudioChunkSize 300 + + # Maximum number of samples to buffer in playback queue. + EspeakAudioQueueMaxSize 441000 diff --git a/debian/patches/series b/debian/patches/series index 1f09fb7..5619c8a 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -2,3 +2,4 @@ doc-figures systemd-debian mbrola-paths generic-set-voice-name +buffer_size
Bug#1025173: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2022g
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
tzdata 2022g was released, so I've uploaded
libdatetime-timezone-perl/1:2.47-1+2022g to bullseye with the data
changes as a quilt patch.
Information from tzdata upstream about the changes:
Changes to future timestamps
In the Mexican state of Chihuahua, the border strip near the US
will change to agree with nearby US locations on 2022-11-30.
The strip's western part, represented by Ciudad Juárez, switches
from -06 all year to -07/-06 with US DST rules, like El Paso, TX.
The eastern part, represented by Ojinaga, will observe US DST next
year, like Presidio, TX. (Thanks to Heitor David Pinto.)
A new Zone America/Ciudad_Juarez splits from America/Ojinaga.
Much of Greenland, represented by America/Nuuk, stops observing
winter time after March 2023, so its daylight saving time becomes
standard time. (Thanks to Jonas Nyrup and Jürgen Appel.)
A manually stripped down debdiff is attached.
Thanks in advance,
gregor
-BEGIN PGP SIGNATURE-
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmOHkTRfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qga/WQ//UkDeY2YazD4np7Coyv1fzrceMmU+WpMkVGE+3byb66Xkw+N8MOFYEKRb
SHYNNEDrARmflDimPRjZkGgchdXU789HGHbB+tAKYE5Ev1WEMIKjbLsL9zkV6G09
UjFe5SIoY3V90jblOONtRWUxHaO5DsKt9jQYRc7LHbsEdgQq+Nkq+Kj+jCHGILXo
1nLxi/Qxe6vbozFVQewTJery7pg706tQzxzKfR+9t8maS+dpf88aVoJoRld98yvc
5n2WyHZS8CcJsrHvqkBiZtRoyde5kN4x/bO8Y1xdme+ToUJ3aJLmWNmnPbLaIe7H
tI8LnPCziVyYjf/il3FVkD2EwoxfZZEMng2jkYo1At1azYOcCLTpM46OYI3SoCBW
i5sBp0A6FtA1+5JlE2zXz59ofbeoVCk+w6FZnuQe+OQcbEGpC7kra9zr/gnZylXl
6k1nmjDucmvSnDzChbOclEZR95B1z/d+iCwzdkiTpDK3sGCTNNZsqqc6gMeb250I
WvmxYvx/dY0Y/6tqkQuKwipT904h/6YJ/ccWRPtxZzMd4FG+ghtkTQxQ7aQ8wXuv
liOdNs63JsZTjT2RpfoinmnBZpzKAZvwlC165zqdUGr8eT3kGuU903eksBOgLETG
eM3HdZbmFgbbCBKi5QSDZZm7MV71cBN8E/jqQACRCg9oFks1Z1I=
=qen3
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2022-10-29
22:24:15.0 +0200
+++ libdatetime-timezone-perl-2.47/debian/changelog 2022-11-30
18:14:07.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.47-1+2022g) bullseye; urgency=medium
+
+ * Update data to Olson database version 2022g.
+This update contains contemporary changes for Mexico and Greenland.
+
+ -- gregor herrmann Wed, 30 Nov 2022 18:14:07 +0100
+
libdatetime-timezone-perl (1:2.47-1+2022f) bullseye; urgency=medium
* Update to Olson database version 2022f.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2022g
libdatetime-timezone-perl-2.47/debian/patches/olson-2022g
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2022g 1970-01-01
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2022g 2022-11-30
18:14:07.0 +0100
@@ -0,0 +1,10257 @@
+Description: Update to Olson DB 2022g
+Origin: vendor
+Author: gregor herrmann
+Last-Update: 2022-11-30
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2022f
++# Generated from debian/tzdata/africa. Olson data version 2022g
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+
+-sub olson_version {'2022f'}
++sub olson_version {'2022g'}
+
+ sub has_dst_changes {0}
+
+--- /dev/null
b/lib/DateTime/TimeZone/America/Ciudad_Juarez.pm
+@@ -0,0 +1,881 @@
++# This file is auto-generated by the Perl DateTime Suite time zone
++# code generator (0.08) This code generator comes with the
++# DateTime::TimeZone module distribution in the tools/ directory
++
++#
++# Generated from debian/tzdata/northamerica. Olson data version 2022g
++#
++# Do not edit this file directly.
++#
++package DateTime::TimeZone::America::Ciudad_Juarez;
++
++use strict;
++use warnings;
++use namespace::autoclean;
++
++our $VERSION = '2.47';
++
++use Class::Singleton 1.03;
++use DateTime::TimeZone;
++use DateTime::TimeZone::OlsonDB;
++
++@DateTime::TimeZone::America::Ciudad_Juarez::ISA = ( 'Class::Singleton',
'DateTime::TimeZone' );
++
++my $spans =
++[
++[
++DateTime::TimeZone::NEG_INFINITY, #utc_start
++60620943600, # utc_end 1922-01-01 07:00:00 (Sun)
++DateTime::TimeZone::NEG_INFINITY, # local_start
++60620918044, #local_end 1921-12-31 23:54:04 (Sat)
++-25556,
++0,
++'LMT',
++],
++[
++60620943600, #utc_start 1922-01-01 07:00:00 (Sun)
++60792616800, # utc_end 1927-06-11 06:00:00 (Sat)
++60620918400, # local_start 1922-01-01 00:00:00 (Sun)
++60792591600, #local_end 1927-06-10 23:00:00 (Fri)
++-25200,
Bug#1023495: transition: ruby3.1
On Wed, Nov 23, 2022 at 05:35:18PM +0100, Sebastian Ramacher wrote: > Hi Antonio > > On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > > Hi Lucas, > > > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > > After discussing with Antonio, since our deadline to finish the > > > > > transition is approaching, we decided to already enable ruby3.1 as the > > > > > default and remove ruby3.0 in a single step. > > > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of > > > > the > > > > default a forward rebuild, while removal is a backward rebuild (I mean > > > > in > > > > the dependency tree)? If that's true, I think doing it in two steps is > > > > easier to manage, as packages can then migrate on their own and don't > > > > need a > > > > lock step migration. > > > > > > That's correct. I'd prefer to handle this with two trackers. > > > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > > start the transition in unstable? > > I'd like protobuf to migrate first which is currently doing its own > transition. Afer that, we can go ahead with the switch to 3.1 as > default. protobuf migrate a few days ago, so I just uploaded ruby-defaults. Please binNMU these packages: epic5 graphviz ignition-math kamailio klayout kross-interpreters libprelude marisa ngraph-gtk notmuch obexftp redland-bindings subtle subversion vim-command-t weechat xapian-bindings signature.asc Description: PGP signature
Processed: RM: simbody [mips64el ppc64el] -- ROM; FTBFS on mips64el and ppc64el
Processing control commands: > block 1024989 by -1 Bug #1024989 [release.debian.org] transition: simbody 1024989 was not blocked by any bugs. 1024989 was not blocking any bugs. Added blocking bug(s) of 1024989: 1025146 -- 1024989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024989 1025146: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025146 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
