Uploading linux (5.8.14-1)
Hi I would like to upload a new linux version 5.8.14-1 to unstable today (or tomorrow) to catch up with the v5.8.y stable series. An ABI bump is included. The pending changes in the packaging are furthermore: * [armhf] Enable MFD_AXP20X_RSB as a built-in (Closes: #914813). * [x86] Enable INTEL_PMC_CORE as module (Closes: #971017) Regards, Salvatore signature.asc Description: PGP signature
Re: Bug#971807: buster-pu: package webext-tbsync
Hello Am 10.10.20 um 11:41 schrieb Adam D. Barratt: > On Sat, 2020-10-10 at 11:16 +0200, Mechtilde Stehmann wrote: >> Hello Adam, > > Hi, > > I've replied to the bug, as that's where you raised the questions, but > as this is trending towards general discussion we should possibly move > it to the debian-release list instead. For me it is ok Since RT updated Thunderbird in buster from version 68.x to 78.x this causes the incompatibility from webext-tbsync with the recent Thunderbird version in Buster. >>> >>> For the record, the Release Team have done no such thing. The >>> Security Team have released 78.x, which is not yet even in stable- >>> new, yet alone buster (although it likely will be in buster after >>> the next point release). >> Ok, I want to understand it and to document it properly. >> >> The secutity-team does the the update of thunderbird from 68.x to >> 78.x in buster. > The package _has been_ released, and will be available to any user of > stable who has the security archive in their APT sources (which > *should* be all of them). That is not in dispute. It is just not yet > part of the stable distribution in the main archive, "only" in the > security archive. This is a detail of the process that I expect and > appreciate that most users will never care about or possibly even be > particularly aware of. I want to clarify one further situation. Thunderbird 78.3 was uploaded by security team to update from version 68.x Webext-tbsync version 2.11 works fine with thunderbird 68.x. but it doesn't work with thunderbird 78.x. For thunderbird 78.x you need version 2.16 mandatorily. In the meantime there is thunderbird 78.x in buster (security) and webext-tbsync version 2.11 in buster. This combination is incompatible (broken). How can we handle such things in a better way in the future? Kind regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Processed: libdata-alias-perl: FTBFS with Perl 5.32: t/03_copy.t failure
Processing control commands: > block 968912 with -1 Bug #968912 [release.debian.org] transition: perl 5.32 968912 was blocked by: 961208 968913 961155 960863 961157 961152 961154 964902 968912 was not blocking any bugs. Added blocking bug(s) of 968912: 971969 -- 968912: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968912 971969: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#968852: marked as done (transition: cfitsio)
Your message dated Sat, 10 Oct 2020 18:03:39 +0200 with message-id <20201010160339.gc4003...@ramacher.at> and subject line Re: Bug#968852: transition: cfitsio has caused the Debian Bug report #968852, regarding transition: cfitsio 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.) -- 968852: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968852 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 Dear release team, I would like to request a transition slot for cfitsio, changing the library name from libcfitsio8 to libcfitsio9. The version 3.480 introducing the ABI change has been in experimental for a few months. I have just uploaded version 3.490 which is a mostly a bug fixes release without new features. I have locally rebuilt all the reversed dependencies on amd64, and found only 3 FTBFS for packages that are only in sid: - freeture (#922579) - munipack (#957572) - theli (#968638) There is already a tracker available here: https://release.debian.org/transitions/html/auto-cfitsio.html Thanks for considering Regards Aurelien -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) --- End Message --- --- Begin Message --- On 2020-08-22 14:02:07 +0200, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > I would like to request a transition slot for cfitsio, changing the > library name from libcfitsio8 to libcfitsio9. The version 3.480 > introducing the ABI change has been in experimental for a few months. I > have just uploaded version 3.490 which is a mostly a bug fixes release > without new features. After vips finally migrated, the old libs got removed from testing. Closing. Cheers > > I have locally rebuilt all the reversed dependencies on amd64, and found > only 3 FTBFS for packages that are only in sid: > - freeture (#922579) > - munipack (#957572) > - theli (#968638) > > There is already a tracker available here: > > https://release.debian.org/transitions/html/auto-cfitsio.html > > Thanks for considering > > Regards > Aurelien > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#968580: marked as done (transition: ilmbase/openexr)
Your message dated Sat, 10 Oct 2020 18:02:59 +0200 with message-id <20201010160259.gb4003...@ramacher.at> and subject line Re: Bug#968580: transition: ilmbase/openexr has caused the Debian Bug report #968580, regarding transition: ilmbase/openexr 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.) -- 968580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968580 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: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org Dear Release Team, I'm filing this bug for a new transition of ilmbase/openexr packages. On August 15th, 2020 good-shaped testing-purpose packages (2.5.3-1) for both ilmbase and openexr have been uploaded to experimental. So, following a checklist obtained via 'reverse-depends', here is the list of source packages depending on ilmbase and openexr and the results of the test builds (honoring the dependency levels as reported in the checklist, as relevant for the correct order): ### Dependency level 2 ### * aqsis_1.8.2-12 => OK * calligra_1:3.2.1+dfsg-2 => OK * darktable_3.2.1-2 => OK * exactimage_1.0.2-7 => FTBFS (possibly OpenEXR-related) * field3d_1.7.2-1 => OK * freeimage_3.18.0+ds2-5 => OK * gegl_0.4.24-1 => OK * imagemagick_8:6.9.11.24+dfsg-1 => OK * kimageformats_5.70.0-1 => OK * kio-extras_4:19.12.3-1 => OK * krita_1:4.3.0+dfsg-1 => OK * libvigraimpex_1.11.1+dfsg-7 => OK * luminance-hdr_2.6.0+dfsg-2 => OK * mia_2.4.7-1 => OK * nvidia-texture-tools_2.0.8-1+dfsg-8.2 => OK * opencv_4.2.0+dfsg-6 => OK * openexr-viewers_2.3.0-1 => OK * openvdb_7.0.0-3 => FTBFS (not OpenEXR-related) * pink-pony_1.4.1-2.1 => OK * povray_1:3.7.0.8-4 => OK * slic3r-prusa_2.2.0+dfsg1-2 => OK ### Dependency level 3 ### * gimp_2.10.18-1 => OK * gst-plugins-bad1.0_1.16.2-2.3 => OK * hugin_2019.2.0+dfsg-2 => OK * k3d_0.8.0.6-8 => FTBFS (missing B-D) * openimageio_2.1.18.1~dfsg0-1 => OK * pfstools_2.1.0-5 => FTBFS (not OpenEXR-related) * synfig_1.2.2+dfsg-3 => OK ### Dependency level 4 ### * blender_2.83.4+dfsg-1 => OK * gmic_2.4.5-1.1 => OK * olive-editor_20200528-1 => OK I'll follow-up this bug report with any progress in fixing the packages that are FTBFS. Thanks for your time and patience. mfv Ben file: title = "ilmbase"; is_affected = .depends ~ "libilmbase24" | .depends ~ "libilmbase25"; is_good = .depends ~ "libilmbase25"; is_bad = .depends ~ "libilmbase24"; title = "openexr"; is_affected = .depends ~ "libopenexr24" | .depends ~ "libopenexr25"; is_good = .depends ~ "libopenexr25"; is_bad = .depends ~ "libopenexr24"; -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature --- End Message --- --- Begin Message --- On 2020-08-17 23:47:33 +0200, Matteo F. Vescovi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org > > Dear Release Team, > > I'm filing this bug for a new transition of ilmbase/openexr packages. After vips finally migrated, the old libs got removed from testing. Closing. Cheers > > On August 15th, 2020 good-shaped testing-purpose packages (2.5.3-1) for > both ilmbase and openexr have been uploaded to experimental. > > So, following a checklist obtained via 'reverse-depends', here is the > list of source packages depending on ilmbase and openexr and the results > of the test builds (honoring the dependency levels as reported in the > checklist, as relevant for the correct order): > > ### Dependency level 2 ### > * aqsis_1.8.2-12 => OK > * calligra_1:3.2.1+dfsg-2 => OK > * darktable_3.2.1-2 => OK > * exactimage_1.0.2-7 => FTBFS (possibly OpenEXR-related) > * field3d_1.7.2-1 => OK > * freeimage_3.18.0+ds2-5 => OK > * gegl_0.4.24-1 => OK > * imagemagick_8:6.9.11.24+dfsg-1 => OK > * kimageformats_5.70.0-1 => OK > * kio-extras_4:19
Bug#971415: transition: ocaml
Hi Stéphane On 2020-09-30 09:12:20 +0200, Stéphane Glondu wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org > > Dear Release Team, > > I've updated ocaml to 4.11.1 and uploaded to experimental. It builds on > all release architectures, and most of ports as well (fixes for > hurd-i386 are pending, and it's still not built on kfreebsd-*). > > The main change as far as Debian is concerned is the split of the > graphics library, which I packaged (as ocaml-graphics) and has been > accepted. > > I tried to install all corresponding opam packages in a 4.11.1 switch, > and the breakage is minimal. Have bugs been filed for the these issues or are you taking care of that? Best > > Therefore, I think we can proceed to updating OCaml in unstable. > > > Cheers, > > -- > Stéphane > > Ben file: > > title = "ocaml"; > is_affected = .depends ~ "ocaml.*4\.08\.1" | .depends ~ "ocaml.*4\.11\.1"; > is_good = .depends ~ "ocaml.*4\.11\.1"; > is_bad = .depends ~ "ocaml.*4\.08\.1"; > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: Re: Bug#971958: transition: libpgm
Processing control commands: > tags -1 + confirmed Bug #971958 [release.debian.org] transition: libpgm Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/auto-libpgm.html Bug #971958 [release.debian.org] transition: libpgm Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libpgm.html'. > block -1 by 971957 Bug #971958 [release.debian.org] transition: libpgm 971958 was not blocked by any bugs. 971958 was not blocking any bugs. Added blocking bug(s) of 971958: 971957 -- 971958: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971958 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971958: transition: libpgm
Control: tags -1 + confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-libpgm.html Control: block -1 by 971957 On 2020-10-10 17:37:57 +0200, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi RMs, > > I'm asking for a small transition of libpgm. Two packages are > affected, libxs and zeromq3. The latter builds fine with libpgm 5.3 in > experimental. Please go ahead. > The question is libxs because while I submitted a patch [1] that fixes > its FTBFS with libpgm 5.3, it seems to be a dead weight. The upstream > of it [2] disappeared. Popcon shows nine users and its maintainer > didn't update it for four and half years (ie Standards-Version is > still 3.9.7, debhelper level is 9). There are also no reverse dependencies. libxs looks like a removal candidate to me. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: Re: Bug#971942: transition: ufo-core
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-ufo-core.html Bug #971942 [release.debian.org] transition: ufo-core Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-ufo-core.html'. > tags -1 + moreinfo Bug #971942 [release.debian.org] transition: ufo-core Added tag(s) moreinfo. -- 971942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971942 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971942: transition: ufo-core
Control: forwarded -1 https://release.debian.org/transitions/html/auto-ufo-core.html Control: tags -1 + moreinfo On 2020-10-10 11:40:13 +0200, Picca Frédéric-Emmanuel wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pi...@debian.org > > (please explain about the transition: impacted packages, reason, ... > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > > Hello, > > I request a slot for the ufo-core transition. > the auto-ufo-core ben file seems ok to me > > I checked that all packages are ok in experimental. There's only ufo-filters which is also staged in experimental, so I don't expect any actions required from the release team. Please feel free to go ahead with the upload to unstable. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#971958: transition: libpgm
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, I'm asking for a small transition of libpgm. Two packages are affected, libxs and zeromq3. The latter builds fine with libpgm 5.3 in experimental. The question is libxs because while I submitted a patch [1] that fixes its FTBFS with libpgm 5.3, it seems to be a dead weight. The upstream of it [2] disappeared. Popcon shows nine users and its maintainer didn't update it for four and half years (ie Standards-Version is still 3.9.7, debhelper level is 9). Thanks, Laszlo/GCS [1] https://bugs.debian.org/971957 [2] https://github.com/crossroads-io/libxs
Bug#971954: buster-pu: package libdatetime-timezone-perl/1:2.23-1+2020b
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-p...@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've uploaded libdatetime-timezone-perl/1:2.23-1+2020b to buster.
It contains the changes of the tzdata 2020b release as a quilt patch
against the Perl data files.
The changes of the Olson db 2020b release are (taken from their
upstream announcement):
Revised predictions for Morocco's changes starting in 2023.
Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08.
Macquarie Island has stayed in sync with Tasmania since 2011.
Casey, Antarctica is at +08 in winter and +11 in summer.
I'm attaching a (manually stripped down) debdiff.
Cheers,
gregor
-BEGIN PGP SIGNATURE-
iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl+Byh9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYOHRAAtA09Ofet6hippTAGUGcoWVpJ8O9kdMsg9SNVEtFvBCP0WeMYEIBcPLKe
XC4LO+YKqVDDpaDXAzTVLnSIV32uP83xe9oPNLpoteT+PsYLYgQyjy/CAV85zEGf
bRA56GutJfVx4AQR8OhQuCGqjBO8bQIceJwecCgCHlgDMy7MtmC4xZ99v9gcE+NQ
drIgS6KiXEOyztMmABdcRr709VLIPXZ7Cr/OcaLAuMsuDLQ2xEzvzpJgHWph6xIu
lhZSt9lyTh++0vPE2e328abKqV7wr2J20EqFkT7Ycn/IbAhtEVSJ8pqG6LzscbPD
kd9+goiFDsvNUAu4mj+NhPGEghOGuMPY/0rsL72ykH8YWxQ4J3THPtXzP0Krifd9
1WWzgTBRvdJ6FP/nXZ5XF4M/GfW0f9WixHfOFr3sczcRM1T+DqVs+Hwnh12LgBCX
Z5vfmet0ti4gMtVIwjVJzUx3qmuYFwCg9AahkQr62O2/i/f7APvAUFmZkra6IkD5
dY+jock+yViyT4UWPCBWNsF2mhuzcG4nAANEE92X0r4ap8EQ9jRIYYKQS54uqukH
4vy48K4kYYhIlN0/3c2kx0sPuFZS0rfSDGxgxchXmPDMjxxfUfrEorVrnZ06apDa
gkkm6k/5FzPpKKdnXUWZ2jxsmjwL5gRY9MNrh3dy7zZQ8bAS6g4=
=c3TQ
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.23/debian/changelog
libdatetime-timezone-perl-2.23/debian/changelog
--- libdatetime-timezone-perl-2.23/debian/changelog 2020-04-24
18:30:12.0 +0200
+++ libdatetime-timezone-perl-2.23/debian/changelog 2020-10-10
16:35:48.0 +0200
@@ -1,3 +1,12 @@
+libdatetime-timezone-perl (1:2.23-1+2020b) buster; urgency=medium
+
+ * Update to Olson database version 2020b.
+This update includes contemporary changes for Morocco, Casey Station, and
+the Yukon. This release also removes the very long-deprecated
+"US/Pacific-New" zone name.
+
+ -- gregor herrmann Sat, 10 Oct 2020 16:35:48 +0200
+
libdatetime-timezone-perl (1:2.23-1+2020a) buster; urgency=medium
* Update to Olson database version 2020a.
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/olson-2020b
libdatetime-timezone-perl-2.23/debian/patches/olson-2020b
--- libdatetime-timezone-perl-2.23/debian/patches/olson-2020b 1970-01-01
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/patches/olson-2020b 2020-10-10
16:35:48.0 +0200
@@ -0,0 +1,11184 @@
+Description: Update to Olson DB 2020b
+Origin: vendor
+Author: gregor herrmann
+Last-Update: 2020-10-10
+
+--- 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 2020a
++# Generated from debian/tzdata/africa. Olson data version 2020b
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+
+-sub olson_version {'2020a'}
++sub olson_version {'2020b'}
+
+ sub has_dst_changes {0}
+
+--- a/lib/DateTime/TimeZone/Africa/Casablanca.pm
b/lib/DateTime/TimeZone/Africa/Casablanca.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2020a
++# Generated from debian/tzdata/africa. Olson data version 2020b
+ #
+ # Do not edit this file directly.
+ #
+@@ -601,17 +601,17 @@
+ ],
+ [
+ 63814874400, #utc_start 2023-03-19 02:00:00 (Sun)
+-63817898400, # utc_end 2023-04-23 02:00:00 (Sun)
++63818503200, # utc_end 2023-04-30 02:00:00 (Sun)
+ 63814874400, # local_start 2023-03-19 02:00:00 (Sun)
+-63817898400, #local_end 2023-04-23 02:00:00 (Sun)
++63818503200, #local_end 2023-04-30 02:00:00 (Sun)
+ 0,
+ 1,
+ '+00',
+ ],
+ [
+-63817898400, #utc_start 2023-04-23 02:00:00 (Sun)
++63818503200, #utc_start 2023-04-30 02:00:00 (Sun)
+ 63845719200, # utc_end 2024-03-10 02:00:00 (Sun)
+-63817902000, # local_start 2023-04-23 03:00:00 (Sun)
++63818506800, # local_start 2023-04-30 03:00:00 (Sun)
+ 63845722800, #local_end 2024-03-10 03:00:00 (Sun)
+ 3600,
+ 0,
+@@ -745,17 +745,17 @@
+ ],
+ [
+ 64059818400, #utc_start 2030-12-22 02:00:00 (Sun)
+-64062842400, # utc_end 2031-01-26 02:00:00 (Sun)
++64063447200, # utc_end 2031-02-02 02:00:00 (Sun)
+ 64059818400, # local_start 2030-12-22 02:00:00 (Sun)
+-64062842400, #local_end 2031-01-26 02:00:00 (Sun)
++64063447200, #local_end 2031-02-02 02:00:00 (Sun)
+ 0,
+ 1,
+ '+00',
+ ]
Bug#971866: buster-pu: package okular/4:17.12.2-2.2+deb10u1
On Sat, Oct 10, 2020 at 09:40:05AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2020-10-08 at 21:15 +0200, Moritz Muehlenhoff wrote: > > Low severity fix for Okular, which doesn't warrant a DSA. > > I've tested with the reproducerand a number of other PDF > > files that everything works as expected. > > > > Please go ahead. Uploaded. Cheers, Moritz
Bug#971915: buster-pu: package transmission/2.94-2+deb10u2
On Sat, Oct 10, 2020 at 09:44:31AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2020-10-09 at 19:40 +0200, Moritz Muehlenhoff wrote: > > Fixes a memory leak when running Transmission in daemon mode. > > > > [ Tests ] > > Have been using the package since a few weeks and the user > > who reported the leak (running an affected setup) confirmed > > that it fixes the leak. > > Please go ahead. Uploaded. Cheers, Moritz
Bug#971869: buster-pu: package freecol/0.11.6+dfsg2-2+deb10u1
On Sat, Oct 10, 2020 at 09:41:38AM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2020-10-08 at 21:20 +0200, Moritz Muehlenhoff wrote: > > Low severity bugfix for freecol, which doesn't warrant a DSA. > > > > The (identical) patch has been in unstable for half a year, also > > doublechecked by playing for half an hour :-) > > Please go ahead. Uploaded. Cheers, Moritz
Bug#971944: buster-pu: package espeak/1.48.04+dfsg-7+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hello, [ Reason ] Espeak cannot drive the mbrola-fr4 speech synthesis voice if the mbrola-fr1 package is not installed. This is because some of the mb-fr4 espeak rules refer to the fr1 voice while they should be referring to the fr4 voice. This was fixed some time ago in the newer espeak-ng package, but the fix was not backported yet to espeak. [ Impact ] This was not a regression over oldstable, but it's hard for users to guess that espeak+mbrola-fr4 cannot work without the mbrola-fr1 package, I actually got hit by the issue a week ago and it took me some time to realize the problem, even though I'm maintaining the packages. [ Tests ] After installing speech-dispatcher, espeak, and mbrola-fr4, but not mbrola-fr1, spd-say -O espeak-mbrola-generic Bonjour should be speaking "Bonjour" [ Risks ] The change is trivial, as attached. It is already tested as working in unstable. [ 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 ] They simply fix the fr1 reference into fr4. Yes, the remaining reference to fr1_phtrans is on purpose, it is part of the confusion between mbrola-fr1 and mbrola-fr4: fr1_phtrans is provided by espeak-data for both mbrola-fr1 and mbrola-fr4, it was actually renamed to fr_phtrans in espeak-ng-data. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru espeak-1.48.04+dfsg/debian/changelog espeak-1.48.04+dfsg/debian/changelog --- espeak-1.48.04+dfsg/debian/changelog2018-10-23 18:26:10.0 +0200 +++ espeak-1.48.04+dfsg/debian/changelog2020-10-10 11:26:41.0 +0200 @@ -1,3 +1,10 @@ +espeak (1.48.04+dfsg-7+deb10u1) buster; urgency=medium + + * patches/mbrola-fr4: Fix using espeak with mbrola-fr4 when mbrola-fr1 is +not installed. + + -- Samuel Thibault Sat, 10 Oct 2020 11:26:41 +0200 + espeak (1.48.04+dfsg-7) unstable; urgency=medium * control: Bump Standards-Version to 4.2.0 (no changes). diff -Nru espeak-1.48.04+dfsg/debian/patches/mbrola-fr4 espeak-1.48.04+dfsg/debian/patches/mbrola-fr4 --- espeak-1.48.04+dfsg/debian/patches/mbrola-fr4 1970-01-01 01:00:00.0 +0100 +++ espeak-1.48.04+dfsg/debian/patches/mbrola-fr4 2020-10-07 22:53:16.0 +0200 @@ -0,0 +1,22 @@ +diff --git a/espeak-data/voices/mb/mb-fr4 b/espeak-data/voices/mb/mb-fr4 +index 8e3c392..6e459cc 100755 +--- a/espeak-data/voices/mb/mb-fr4 b/espeak-data/voices/mb/mb-fr4 +@@ -5,5 +5,5 @@ gender female + dictrules 1 + pitch 140 220 + voicing 90 +-mbrola fr1 fr1_phtrans ++mbrola fr4 fr1_phtrans + +diff --git a/espeak-data/voices/mb/mb-fr4-en b/espeak-data/voices/mb/mb-fr4-en +index 8126770..33817e5 100755 +--- a/espeak-data/voices/mb/mb-fr4-en b/espeak-data/voices/mb/mb-fr4-en +@@ -5,5 +5,5 @@ gender female + dictrules 1 + pitch 140 220 + voicing 90 +-mbrola fr1 fr1_phtrans ++mbrola fr4 fr1_phtrans + diff -Nru espeak-1.48.04+dfsg/debian/patches/series espeak-1.48.04+dfsg/debian/patches/series --- espeak-1.48.04+dfsg/debian/patches/series 2016-09-11 02:42:30.0 +0200 +++ espeak-1.48.04+dfsg/debian/patches/series 2020-10-07 22:53:16.0 +0200 @@ -3,3 +3,4 @@ fpic char_cast path +mbrola-fr4
Bug#971807: buster-pu: package webext-tbsync
On Sat, 2020-10-10 at 11:16 +0200, Mechtilde Stehmann wrote: > Hello Adam, Hi, I've replied to the bug, as that's where you raised the questions, but as this is trending towards general discussion we should possibly move it to the debian-release list instead. > Am 07.10.20 um 21:45 schrieb Adam D. Barratt: > > On Wed, 2020-10-07 at 21:24 +0200, Mechtilde Stehmann wrote: > > > Hello Adam, > > > > > > On Wed, 07 Oct 2020 19:54:41 +0100 "Adam D. Barratt" > > > wrote:> severity 971807 normal > > ... > > > > Since RT updated Thunderbird in buster from version 68.x to 78.x > > > this causes the incompatibility from webext-tbsync with the > > > recent Thunderbird version in Buster. > > > > For the record, the Release Team have done no such thing. The > > Security Team have released 78.x, which is not yet even in stable- > > new, yet alone buster (although it likely will be in buster after > > the next point release). > > > > I realise this might seem picky, but if you're going to say we > > caused it... :-) > > Ok, I want to understand it and to document it properly. > > The secutity-team does the the update of thunderbird from 68.x to > 78.x in buster. > > As I did an apt update && apt list --upgradable it already shows > thunderbird 1:78.x in buster. So for me thunderbird 78.x is already > released. Where / how does it show that the package is "in buster"? Your sources.list contains an entry for the security archive, which will be "(security|deb).debian.org/debian-security buster/updates main" or similar. As such the package is "in buster/updates" or "in buster- security", but not "in buster". The package _has been_ released, and will be available to any user of stable who has the security archive in their APT sources (which *should* be all of them). That is not in dispute. It is just not yet part of the stable distribution in the main archive, "only" in the security archive. This is a detail of the process that I expect and appreciate that most users will never care about or possibly even be particularly aware of. Note that this does not in general mean that an update required to stable by another update in the security archive cannot be made. I would not have mentioned it at all, if you had not yourself said that the Release Team had made the update to thunderbird. I was not honestly expecting that comment to generate this much process discussion. :-) > How can I follow up which package is in stable-new and not already in > stable? As a starting point, if the DSA was released since the most recent point release, then the package cannot be in stable yet, as stable only changes with point releases, which happen roughly every couple of months. APT will also show the difference: $ apt-cache policy thunderbird thunderbird: Installed: (none) Candidate: 1:78.3.1-2~deb10u2 Version table: 1:78.3.1-2~deb10u2 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages 1:68.12.0-1~deb10u1 500 500 http://deb.debian.org/debian buster/main amd64 Packages and for a package that has already been included in a point release: $ apt-cache policy ark ark: Installed: (none) Candidate: 4:18.08.3-1+deb10u2 Version table: 4:18.08.3-1+deb10u2 500 500 http://deb.debian.org/debian buster/main amd64 Packages 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages The current status of packages being potentially included in the next point release (either via p-u, or imported from the security archive) can be seen at https://release.debian.org/proposed-updates/stable.html , with the top table corresponding to stable-new. As stable-new is "just" another suite (well, it's a policy queue, but for users that's again mostly an archive implementation detail), you can also see the status of the package using rmadison, or dak on a couple of DD-accessible hosts: $ rmadison thunderbird -s stable,stable-new thunderbird | 1:60.9.0-1~deb10u1 | stable | source, armel, armhf thunderbird | 1:68.12.0-1~deb10u1 | stable | source, amd64, arm64, i386, mips64el, ppc64el, s390x thunderbird | 1:78.3.1-2~deb10u1 | stable-new | source, amd64, arm64, mips64el, ppc64el thunderbird | 1:78.3.1-2~deb10u2 | stable-new | source, amd64, arm64, i386, mips64el, ppc64el I hope that helps resolve any queries you had regarding the process and my earlier comment. Regards, Adam
Bug#971942: transition: ufo-core
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pi...@debian.org (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Hello, I request a slot for the ufo-core transition. the auto-ufo-core ben file seems ok to me I checked that all packages are ok in experimental. thanks for considering Frederic -- System Information: Debian Release: bullseye/sid APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#971807: buster-pu: package webext-tbsync
Hello Adam, Am 07.10.20 um 21:45 schrieb Adam D. Barratt: > On Wed, 2020-10-07 at 21:24 +0200, Mechtilde Stehmann wrote: >> Hello Adam, >> >> On Wed, 07 Oct 2020 19:54:41 +0100 "Adam D. Barratt" >> wrote:> severity 971807 normal ... >> Since RT updated Thunderbird in buster from version 68.x to 78.x this >> causes the incompatibility from webext-tbsync with the recent >> Thunderbird version in Buster. > > For the record, the Release Team have done no such thing. The Security > Team have released 78.x, which is not yet even in stable-new, yet alone > buster (although it likely will be in buster after the next point > release). > > I realise this might seem picky, but if you're going to say we caused > it... :-) Ok, I want to understand it and to document it properly. The secutity-team does the the update of thunderbird from 68.x to 78.x in buster. As I did an apt update && apt list --upgradable it already shows thunderbird 1:78.x in buster. So for me thunderbird 78.x is already released. How can I follow up which package is in stable-new and not already in stable? Kind regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Bug#970816: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2+deb10u1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 2020-10-10 at 09:21 +0100, Adam D. Barratt wrote: > > > > I backported some of the changes to stable (the snapshot and backup > > protocols versions, unfortunately the debug part would require > > backporting others commits). > > Please go ahead. Thanks, uploaded! - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+Bde4ACgkQ3rYcyPpX RFu18QgAroGkfKkkbHZ9xPSNxEoTaRobnt9wnoof4m5D9K011CGLwyTa6+hKR6KU 6/pUw1080Iv+gb4/Agv4yUnJcY04G4yZMk3W3f8bnFjePNKCTJxIB7omwEMwxbkW Sx6QF+QMorfhgnqa7/uYsgy7lLCD0KAKP9o82QIkcjqTF8boFISsuTyQPqgOOqLD GhTSjkUmioHp+mdIn53c0l2arX4xztM4CCS+ISaKa4yvG/hFryZuKSP8uTIKoDNk wJwafaU1CsvkjOmepiCHY5oc2B1P7y2a79rdx3UhIMCAVcWec8xPPSJjSCnTIk8h 5tc6AoUXT7XaOgcPW2zKcfnsDtLECw== =iieH -END PGP SIGNATURE-
Processed: Re: Bug#971915: buster-pu: package transmission/2.94-2+deb10u2
Processing control commands: > tags -1 + confirmed Bug #971915 [release.debian.org] buster-pu: package transmission/2.94-2+deb10u2 Added tag(s) confirmed. -- 971915: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971915 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971915: buster-pu: package transmission/2.94-2+deb10u2
Control: tags -1 + confirmed On Fri, 2020-10-09 at 19:40 +0200, Moritz Muehlenhoff wrote: > Fixes a memory leak when running Transmission in daemon mode. > > [ Tests ] > Have been using the package since a few weeks and the user > who reported the leak (running an affected setup) confirmed > that it fixes the leak. Please go ahead. Regards, Adam
Bug#971869: buster-pu: package freecol/0.11.6+dfsg2-2+deb10u1
Control: tags -1 + confirmed On Thu, 2020-10-08 at 21:20 +0200, Moritz Muehlenhoff wrote: > Low severity bugfix for freecol, which doesn't warrant a DSA. > > The (identical) patch has been in unstable for half a year, also > doublechecked by playing for half an hour :-) Please go ahead. Regards, Adam
Processed: Re: Bug#971866: buster-pu: package okular/4:17.12.2-2.2+deb10u1
Processing control commands: > tags -1 + confirmed Bug #971866 [release.debian.org] buster-pu: package okular/4:17.12.2-2.2+deb10u1 Added tag(s) confirmed. -- 971866: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971866 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#971869: buster-pu: package freecol/0.11.6+dfsg2-2+deb10u1
Processing control commands: > tags -1 + confirmed Bug #971869 [release.debian.org] buster-pu: package freecol/0.11.6+dfsg2-2+deb10u1 Added tag(s) confirmed. -- 971869: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971869 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971866: buster-pu: package okular/4:17.12.2-2.2+deb10u1
Control: tags -1 + confirmed On Thu, 2020-10-08 at 21:15 +0200, Moritz Muehlenhoff wrote: > Low severity fix for Okular, which doesn't warrant a DSA. > I've tested with the reproducerand a number of other PDF > files that everything works as expected. > Please go ahead. Regards, Adam
Bug#971685: buster-pu: package fish/3.0.2-2+deb10u1
Control: tags -1 + moreinfo On Sun, 2020-10-04 at 19:53 -0400, Boyuan Yang wrote: > I am working on solving https://bugs.debian.org/970777 , a bug that > made package fish in Debian 10 unusable with sudo in terminal. The > patch comes from upstream trunk. The metadata for that bug indicates that it is affects the package in unstable and is not yet fixed there - is that correct? If so, then the fix needs to be in unstable before we can consider it for a stable update. If not, please update the metadata to indicate which package version the fix was first included in. Regards, Adam
Processed: Re: Bug#971685: buster-pu: package fish/3.0.2-2+deb10u1
Processing control commands: > tags -1 + moreinfo Bug #971685 [release.debian.org] buster-pu: package fish/3.0.2-2+deb10u1 Added tag(s) moreinfo. -- 971685: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971685 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#971062: buster-pu: package plinth/19.1
Control: tags -1 + confirmed On Sat, 2020-09-26 at 22:38 -0400, James Valleroy wrote: > This update proposes to fix security tracker issue CVE-2020-25073, > where a remote attackers could obtain sensitive information from the > /server-status page of the Apache HTTP Server, because a connection > from the Tor onion service (or from PageKite) is considered a local > connection. Please go ahead. > This issue also exists in stretch. stretch is handled by the LTS team now, so you'll need to contact them if you'd like to update the package there. Regards, Adam
Processed: Re: Bug#971062: buster-pu: package plinth/19.1
Processing control commands: > tags -1 + confirmed Bug #971062 [release.debian.org] buster-pu: package plinth/19.1 Added tag(s) confirmed. -- 971062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971062 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#970745: buster-pu: package pdns_4.1.6-3+deb10u1
Processing control commands: > tags -1 + confirmed Bug #970745 [release.debian.org] buster-pu: package pdns_4.1.6-3+deb10u1 Added tag(s) confirmed. -- 970745: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970745 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#970745: buster-pu: package pdns_4.1.6-3+deb10u1
Control: tags -1 + confirmed On Tue, 2020-09-22 at 22:22 +0200, Chris Hofstaedtler wrote: > Fixes for low-severity issues CVE-2019-10203 and CVE-2020-17482. > Both using upstream patches for the 4.1 branch. Please go ahead. > Maybe it should be pointed out in the stable update notes that > manual action is needed to remedy CVE-2019-10203 for existing > installations using postgres. "Manual schema update required for > PostgreSQL"? We could, but I'm not sure how many people actually read the fine print of the announcement mails, particularly in sections that they expect to be boilerplate. I was wondering if it was worth a d/NEWS entry, although that would obviously be potentially annoying if it ends up being shown to users who don't have the relevant binary package installd. Regards, Adam
Bug#970655: buster-pu: package sleuthkit/4.6.5-1+deb10u1
Control: tags -1 + confirmed On Sun, 2020-09-20 at 20:01 +, Francisco Vilmar Cardoso Ruviaro wrote: > I would like to update the sleuthkit on the buster to prevent a stack > buffer overflow in yaffsfs_istat, because during a review of the > Debian Security Tracker, I found CVE-2020-10232. Please go ahead. Regards, Adam
Processed: Re: Bug#970655: buster-pu: package sleuthkit/4.6.5-1+deb10u1
Processing control commands: > tags -1 + confirmed Bug #970655 [release.debian.org] buster-pu: package sleuthkit/4.6.5-1+deb10u1 Added tag(s) confirmed. -- 970655: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970655 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#970816: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2+deb10u1
Processing control commands: > tags -1 + confirmed Bug #970816 [release.debian.org] buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2+deb10u1 Added tag(s) confirmed. -- 970816: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970816 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#970816: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2+deb10u1
Control: tags -1 + confirmed On Wed, 2020-09-23 at 20:59 +0200, Yves-Alexis Perez wrote: > would it be possible to allow a new libimobiledevice version in > Buster? > > [ Reason ] > > the recently released iOS (and ipadOS) 14 updates some protocols > version used for communication between a host and a device, > especially debug, backup and snapshot services. Upstream has updated > the library, I've already uploaded a fixed version in stable (and it > has migrated to testing). > > I backported some of the changes to stable (the snapshot and backup > protocols versions, unfortunately the debug part would require > backporting others commits). Please go ahead. Regards, Adam
Bug#966373: general: Higher version for uploads to stable and oldstable distributions
On Wed, 2020-10-07 at 20:05 +0200, Javier Serrano Polo wrote: > El dl 21 de 09 de 2020 a les 16:50 +0200, Javier Serrano Polo va > escriure: > > I will elaborate on the problem with 1-1+b1foo1 and 1-1+b1foo1+b1 > > if you are willing to help. > > First, a binNMU in Debian may be unnecessary in the derivative. > Following Debian binNMUs means unnecessary builds in architectures > supported by the derivative and a burden for users in unsupported > architectures. This has nothing specifically to do with updates to stable, and changing the versioning used for source updates to stable will not change it. If stable released with version 1.0-1 of package foo, then it is entirely feasible that a binNMU will be required at some point, and that will be versioned as 1.0-1+b1. If the derivative has previously made a change to foo, then they can version it as 1.0-1+deriv1, and it will not be superseded by the binNMU. If they have not, then operating as an overlay means they must pull in the binNMU. There are absolutely no changes to package versioning that can change these facts, and you must be fully aware of this. > Moreover, the derivative would need to track all binary > changes instead of source changes only. As above, this is a decision that the derivative has made for themselves by choosing to overlay the base Debian archive rather than import changes into their own full distribution. It also conflicts with your original claims that you were trying to avoid having a stable update - which would be a source change - automatically pulled in to the derivative and thus overriding earlier changes made in the derivative. There are two choices for the derivative when making source changes. They either use 1.0-1+deriv1, at which point a future stable update to Debian will not supersede their upload, or they use 1.0-1deriv1 and accept that future updates to Debian will overwrite their changes. Yes, this means work for the derivative. That's an unfortunate fact of life in the space. Either updates to the base distribution automatically get pulled in, and may thus override changes in the derivative, or they do not and the derivative thus has to inspect each upload to the base distribution and decide whether to import it. I believe that your focus on binNMUs here clearly indicates that you are not trying to solve an actual issue with the versioning of *source* uploads to Debian's stable distributions, as there can be no changes to the version scheme used for stable updates that will change anything related to binNMUs. Furthermore, I do not believe that you were unaware of any of these facts before sending your mail. Regards, Adam
