Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi folks, Once again, coming back around to the question of an archive-wide migration for time_t[0]. We have a clear path forward on the toolchain side (https://bugs.debian.org/1037136), and we have an updated ABI analysis done against current Debian unstable as of 2023-12-18, superseding the previous preliminary analysis we had done on Ubuntu mantic. This re-analysis took a while to get done in large part because the earlier mailing list thread revealed gaps in the identification of "dev" packages[1], so we spent some time fixing this to ensure we had proper archive coverage. Output files from the new analysis can be found here: https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/ == Description of methodology == Before going into details of the plan I'm proposing for the migration, I want to surface to the list the methodology used for the analysis, so that people have an opportunity to identify any errors. - Packages are identified as "dev" packages if, according to Contents-armhf in the archive, they ship files with an extension of .h, .hpp, .hxx, or .hh in any directory outside of /usr/share/doc. - Packages are identified as "library" packages if, according to Contents, they ship files with an extension of .so or match the pattern *.so.*. - Source packages are candidates for ABI analysis as part of this transition if at least one of their binary packages is a "dev" package, at least one is a "library" package, and at least one ships a shlibs control file. - This means packages that provide plugin APIs are excluded from the transition (they couldn't be automated anyway), but might still have ABI breakage that will require handling. (ex: apache2-dev; but it looks like perl did get picked up correctly by way of libperl5.36) - In multi-library packages, there is no reliable way to map from a set of headers in a dev package to specific shared libraries in a runtime library package that's not additionally computationally prohibitive; we therefore conservatively assume that if any headers from a source package show time_t ABI changes, all the runtime library packages from the source package are affected by the transition. This seems sensible in general, but er, in the pathological case we have Source: zlib that now ships both zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not be ABI breaking, libminizip-dev has failed to analyze, and we don't want to force a transition for zlib1g because of libminizip (!). Current plan is to simply special case zlib1g, but there could be other problem packages we haven't identified. - Packages that could not be analyzed for whatever reason are still assumed to have an ABI that's sensitive to time_t and have to be included in the transition. Happily, due to improvements in this run of the number of packages that could successfully be analyzed, the number of libraries in this category has dropped from 1541 to 929, of which 69 have no reverse-dependencies at all. The final list of these header packages that could not be analyzed is attached, in case anyone still wants to identify that a library on this list whose ABI is not affected by time_t and should therefore be excluded from the transition. Note, however, that no effort has been made to filter out dev packages from this list that come from source packages containing OTHER dev packages that are known to have ABI breakage; for a number of the packages listed, further analysis would not change the outcome. (e.g. qt5-qmake failed to be analyzed, but qtbase-opensource-src also ships qtbase5-private-dev which shows time_t ABI sensitivity.) == Results == The overall findings of this analysis are 1,745 "dev" packages which either are confirmed to have ABI changes or could not be checked; mapping to 2,154 runtime libraries (list attached) from 1,195 source packages (list attached) and 5,477 reverse-dependencies requiring no-change rebuilds (list attached). This is within the previously calculated range of "5300 to 5600", but there are a number of newly-identified packages that fail to compile and have a large number of reverse-dependencies. I will continue to work to identify false-positives here in the hopes of bringing this count down before pulling the trigger on an actual transition. My understanding is that this will also result in a perl ABI transition, separately from the libperl ABI transition; since this dependency isn't calculated via shlibs it was not automatically included in this analysis. This seems to be at most about 600 additional packages to be included in the transition. In addition, Guillem pointed out that if there are libraries whose ABIs are lfs-sensitive but not time_t-sensitive, and either they themselves depend on libraries which are time_t-sensitive or they have reverse-dependencies that do, so they will also need to be included in the transition. I have identified a list of 53 packages in this
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > - In multi-library packages, there is no reliable way to map from a set of > headers in a dev package to specific shared libraries in a runtime library > package that's not additionally computationally prohibitive; we therefore > conservatively assume that if any headers from a source package show > time_t ABI changes, all the runtime library packages from the source > package are affected by the transition. > 0 dbus-tests Please ignore this specific binary package. The only public API/ABI of src:dbus is in libdbus-1-3 + libdbus-1-dev, so analyzing those two is enough. (dbus-tests accidentally contains one header file, but that's a minor bug.) libdbus-1-dev is widely depended-on, so I hope that taking src:dbus off your list will avoid some unnecessary rebuilds? > 0 gobject-introspection Similarly the only public API/ABI of src:gobject-introspection is in libgirepository1.0-dev, libgirepository-1.0-1, and (in experimental) libgirepository-1.0-dev. gobject-introspection contains some source and header files that are used by other packages' regression tests, but they are not public ABI. smcv
Processed: transition: tpm2-tss
Processing control commands: > affects -1 + src:tpm2-tss Bug #1060058 [release.debian.org] transition: tpm2-tss Added indication that 1060058 affects src:tpm2-tss -- 1060058: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060058 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1058944: transition: petsc
On 2023-12-20 23:31, Sebastian Ramacher wrote: Control: tags -1 confirmed On 2023-12-18 19:02:51 +0100, Drew Parsons wrote: I'd like to upgrade PETSc (and SLEPc, and their python packages) from 3.18 to 3.19. All packages are now built or rebuilt with tests passing. (except for deal.ii which has boost 1.83 issues).
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi,
Am 05.01.24 um 09:17 schrieb Steve Langasek:
- Packages that could not be analyzed for whatever reason are still
assumed to have an ABI that's sensitive to time_t and have to be included
in the transition. Happily, due to improvements in this run of the number
of packages that could successfully be analyzed, the number of libraries
in this category has dropped from 1541 to 929, of which 69 have no
reverse-dependencies at all. The final list of these header packages that
could not be analyzed is attached, in case anyone still wants to identify
that a library on this list whose ABI is not affected by time_t and should
therefore be excluded from the transition. Note, however, that no effort
has been made to filter out dev packages from this list that come from
source packages containing OTHER dev packages that are known to have ABI
breakage; for a number of the packages listed, further analysis would not
change the outcome. (e.g. qt5-qmake failed to be analyzed, but
qtbase-opensource-src also ships qtbase5-private-dev which shows time_t
ABI sensitivity.)
[...]
My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition. Then, starting on Jan 18:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
I think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every
maintainer, but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid
immediately when tagged end of next week to not have this caught in the
transition. (see also below for the comment about new upstream versions
in experimental.)
experimental with the new binary package names in order to clear binary
NEW, in coordination
And what about skipped ones? When will those be tried?
Those also will need clear NEW if needed.
(And they might even FTBFS because the ABI did change and ABI-assuming
test break? Though I don't assume so for time_t, but if time is passed
around... I don't assume so, but...
At least that would be the case for libreoffice (and
libreoffice-dev-common is in the affected set, which means some stuff
relies on it...))
(Maybe even needing asm fixes)
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
Please let me know of any problems with this plan.
Also a problem is that experimental also might already contain totally
unrelated updates like new upstream versions...
Regards,
Rene
Bug#1060077: transition: g2clib
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g2c...@packages.debian.org, sramac...@debian.org Control: affects -1 + src:g2clib There is a minor transition I wish to proceed. g2clib upstream have added an SOVERSION of .0 so the package name has changed libg2c0d -> libg2c0 Three dependencies will need rebuilding: pygrib, ncl and grads. I also maintain these 3 packages and they trivially rebuild. So this can be done in a day, without impacting other transitions. Ben file: title = "g2clib"; is_affected = .depends ~ "libg2c0d" | .depends ~ "libg2c0"; is_good = .depends ~ "libg2c0"; is_bad = .depends ~ "libg2c0d";
Processed: transition: g2clib
Processing control commands: > affects -1 + src:g2clib Bug #1060077 [release.debian.org] transition: g2clib Added indication that 1060077 affects src:g2clib -- 1060077: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060077 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve > - perl will also get a sourceful upload, to manually handle 'perlapi' > Provides. Can we combine this one with the upcoming perl transition? See #1055955. Here are some more comments on individual packages. > 22 libobs-dev That's a change to the plugin ABI only. > 14 gnuradio gnuradio bump its SONAME every other month. > 9 libopenmpt-dev Seems to be a false positive. > 9 libogre-1.9-dev > 9 libgirara-dev Why is this one on the list? > 5 gcc-10-plugin-dev Can be skipped, not part of testing. Should be RMed from the archive instead. > 4 llvm-15-dev llvm-toolchain-15 is scheduled for removal. Reverse dependencies should get an RC bug instead. > 4 libspatialaudio-dev Why is this package on the list? > 3 libdvbpsi-dev Seems to be a false positive > libavutil58 av_timegm is not used by any package in the archive. I'd skip ffmpeg and it's libraries. > libpoppler-cpp0v5 > libpoppler-glib8 > libpoppler-qt5-1 > libpoppler-qt6-3 > libpoppler126 Can be combined with the upcoming poppler transiton (see #1060019) > libvlc5 > libvlccore9 Change to vlc plugin ABI. This does not require a change of the binary package name. > g2clib Can be combined with the upcoming transition (see #1060077). Cheers -- Sebastian Ramacher
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote: > On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > > - In multi-library packages, there is no reliable way to map from a set of > > headers in a dev package to specific shared libraries in a runtime library > > package that's not additionally computationally prohibitive; we therefore > > conservatively assume that if any headers from a source package show > > time_t ABI changes, all the runtime library packages from the source > > package are affected by the transition. > > 0 dbus-tests > Please ignore this specific binary package. The only public API/ABI > of src:dbus is in libdbus-1-3 + libdbus-1-dev, so analyzing those two > is enough. (dbus-tests accidentally contains one header file, but that's > a minor bug.) > libdbus-1-dev is widely depended-on, so I hope that taking src:dbus off > your list will avoid some unnecessary rebuilds? > > 0 gobject-introspection > Similarly the only public API/ABI of src:gobject-introspection is in > libgirepository1.0-dev, libgirepository-1.0-1, and (in experimental) > libgirepository-1.0-dev. gobject-introspection contains some source > and header files that are used by other packages' regression tests, > but they are not public ABI. Yes, sorry - the way my scripts are set up to do the analysis right now, these packages still show up in the `sorted-revdep-count` list but there are manual overrides mapping both of these to an empty set of runtime libraries. So you'll see they don't show up in the `runtime-libs` or `source-packages` lists, and none of the reverse-dependencies of libdbus or libgirepository are tagged for rebuild. https://salsa.debian.org/adrien-n/armhf-time_t/-/blob/c62a594236374469b2181e9c5578ed124b57c48c/packagelist.py#L304 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1060130: bullseye-pu: package libmateweather/1.24.1-1+deb11u1
Hi, unfortunately, this mail left my system before it was complete. See below. On Sa 06 Jan 2024 08:36:21 CET, Mike Gabriel wrote: Please unblock the recent bullseye-pu upload of libmateweather. [ Reason ] Main reason for providing the pu is that Aviation Weather changed their data server URL for retrieving weather information from their servers. While at it, more data changes have been cherry-picked from upstream (see below). [ Impact ] If this pu does not get accepted, Debian users will have a broken weather-applet on MATE desktop. No weather information can be retrieved. [ Tests ] Manually installed the new .deb version and tested the MATE weather applet regarding the introduced changes (on a Debian (Edu) bullseye system). [ Risks ] Regressions are always possible. MATE users will be affected. Esp. when using weather reports on their desktop. [ 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 ] + * debian/patches: Cherry-pick upstream fixes from libmateweather 1.24 branch: ++ add 0001_add-two-brazilian-cities.patch ++ add 0002_remove-Berlin-Tegel.patch + * debian/patches: Cherry-pick upstream fixes from libmateweather 1.26 branch: ++ add (and comment out) 0011_Kyiv-timezone.patch (tzdata in bullseye + still uses the old Europe/Kiew ++ add city: 0012_add-San-Miguel-de-Tucuman-Argentina.patch ++ update Chicago area codes: 0013_Chicago-area-updates.patch ++ update data server URL: 0014_data-server-url-changed.patch (Closes: + #1054248, #1054268) ++ typo fixes in location names: 0005_fix-some-location-names.patch ++ new Tbilisi airport code: 0006_tbilisi-IATA-airport-code-changed.patch ++ Add follow-up patch 0014b_The-url-with-www.-is-a-permanent-redirect-308- + to-the.patch. The url with 'www.aviationweather.gov' is a permanent + redirect (308) to the url without 'www.'. [ Other info ] This bullseye-pu brings libmateweather onto a similar level as libmateweather in bookworm after the bookworm-pu 1.26.0-1.1+deb12u2 (2!) has been accepted (see #1060129). light+love, Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpwvkTs6QQOT.pgp Description: Digitale PGP-Signatur
Bug#1060130: bullseye-pu: package libmateweather/1.24.1-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: libmateweat...@packages.debian.org Control: affects -1 + src:libmateweather Please unblock the recent bullseye-pu upload of libmateweather. [ Reason ] Main reason for providing the pu is that Aviation Weather changed their data server URL for retrieving weather information from their servers. While at it, more data changes have been cherry-picked from upstream (see below). [ Impact ] If this pu does not get accepted, Debian users will have a broken weather-applet on MATE desktop. No weather information can be retrieved. [ Tests ] Manually installed the new .deb version and tested the MATE weather applet regarding the introduced changes (on a Debian (Edu) bullseye system). [ Risks ] Regressions are always possible. MATE users will be affected. Esp. when using weather reports on their desktop. [ 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 ] [ Other info ] (Anything else the release team should know.) diff -Nru libmateweather-1.24.1/debian/changelog libmateweather-1.24.1/debian/changelog --- libmateweather-1.24.1/debian/changelog 2020-08-21 23:20:54.0 +0200 +++ libmateweather-1.24.1/debian/changelog 2023-12-13 14:48:25.0 +0100 @@ -1,3 +1,23 @@ +libmateweather (1.24.1-1+deb11u1) bullseye; urgency=medium + + * debian/patches: Cherry-pick upstream fixes from libmateweather 1.24 branch: ++ add 0001_add-two-brazilian-cities.patch ++ add 0002_remove-Berlin-Tegel.patch + * debian/patches: Cherry-pick upstream fixes from libmateweather 1.26 branch: ++ add (and comment out) 0011_Kyiv-timezone.patch (tzdata in bullseye + still uses the old Europe/Kiew ++ add city: 0012_add-San-Miguel-de-Tucuman-Argentina.patch ++ update Chicago area codes: 0013_Chicago-area-updates.patch ++ update data server URL: 0014_data-server-url-changed.patch (Closes: + #1054248, #1054268) ++ typo fixes in location names: 0005_fix-some-location-names.patch ++ new Tbilisi airport code: 0006_tbilisi-IATA-airport-code-changed.patch ++ Add follow-up patch 0014b_The-url-with-www.-is-a-permanent-redirect-308- + to-the.patch. The url with 'www.aviationweather.gov' is a permanent + redirect (308) to the url without 'www.'. + + -- Mike Gabriel Wed, 13 Dec 2023 14:48:25 +0100 + libmateweather (1.24.1-1) unstable; urgency=medium [ Martin Wimpress ] diff -Nru libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch --- libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch 1970-01-01 01:00:00.0 +0100 +++ libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch 2023-12-13 14:48:25.0 +0100 @@ -0,0 +1,47 @@ +From 90cc76a2b0e8d57ec17a5ca81d00fa7e6808076a Mon Sep 17 00:00:00 2001 +From: raveit65 +Date: Wed, 7 Apr 2021 21:41:14 +0200 +Subject: [PATCH] add 2 brazil cities +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +- Joinville and São Bento do Sul +- fixes https://github.com/mate-desktop/libmateweather/issues/94 +--- + data/Locations.xml.in | 22 ++ + 1 file changed, 22 insertions(+) + +diff --git a/data/Locations.xml.in b/data/Locations.xml.in +index a80dacd1..19b61c00 100644 +--- a/data/Locations.xml.in b/data/Locations.xml.in +@@ -9787,6 +9787,28 @@ + -27.67 -48.55 + + ++ ++ ++ Joinville ++ -26.30444 -48.84556 ++ ++Joinville Airport ++SBJV ++America/Sao_Paulo ++-26.22444 -48.79722 ++ ++ ++ ++ ++ São Bento do Sul ++ -26.25028 -49.37861 ++ ++São Bento do Sul ++SBSB ++America/Sao_Paulo ++-26.25028 -49.37861 ++ ++ + + + diff -Nru libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch --- libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch 1970-01-01 01:00:00.0 +0100 +++ libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch 2023-12-13 14:48:25.0 +0100 @@ -0,0 +1,30 @@ +From 74c7f241a34e85b1aa33daa9fd595b17b65756c1 Mon Sep 17 00:00:00 2001 +From: Benjamin Valentin +Date: Tue, 6 Jul 2021 15:50:47 +0200 +Subject: [PATCH] locations: drop Berlin Tegel + +Berlin Tegel Airport shut down on 4th of May 2021 and will be converted +into the 'Urban Tech Republic' quarters. + +It currently serves as a COVID-19 vaccination center, it
Processed: bookworm-pu: package libmateweather/1.26.0-1.1+deb12u2
Processing control commands: > affects -1 + src:libmateweather Bug #1060129 [release.debian.org] bookworm-pu: package libmateweather/1.26.0-1.1+deb12u2 Added indication that 1060129 affects src:libmateweather -- 1060129: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060129 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060129: bookworm-pu: package libmateweather/1.26.0-1.1+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: libmateweat...@packages.debian.org Control: affects -1 + src:libmateweather A minor fix has been released as libmateweather 1.26.3 which shall be cherry-picked into the libmateweather version in Debian bookworm. [ Reason ] It turned out that the updated URL used for accessing the aviationweather.gov service was permanent redirect. This shall be amended with the next point release. [ Impact ] Minimal, mostly an issue for the service provider of aviationweather.gov (as all Debian stable versions of libmateweather will access their permanent redirect rather than the real target URL). [ Tests ] Manually. [ Risks ] Very low. [ 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 ] + * debian/patches: ++ Add follow-up patch 0004b_The-url-with-www.-is-a-permanent-redirect-308- + to-the.patch. The url with 'www.aviationweather.gov' is a permanent + redirect (308) to the url without 'www.'. (Cherry-picked from v1.26.3). [ Other info ] This is a direct follow-up for libmateweather 1.26.0-1.1+deb12u1. diff -Nru libmateweather-1.26.0/debian/changelog libmateweather-1.26.0/debian/changelog --- libmateweather-1.26.0/debian/changelog 2023-10-31 08:25:09.0 +0100 +++ libmateweather-1.26.0/debian/changelog 2024-01-06 08:27:01.0 +0100 @@ -1,3 +1,12 @@ +libmateweather (1.26.0-1.1+deb12u2) bookworm; urgency=medium + + * debian/patches: ++ Add follow-up patch 0004b_The-url-with-www.-is-a-permanent-redirect-308- + to-the.patch. The url with 'www.aviationweather.gov' is a permanent + redirect (308) to the url without 'www.'. (Cherry-picked from v1.26.3). + + -- Mike Gabriel Sat, 06 Jan 2024 08:27:01 +0100 + libmateweather (1.26.0-1.1+deb12u1) bookworm; urgency=medium * debian/patches: Cherry-pick (and re-arrange) upstream fixes. diff -Nru libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch --- libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch 1970-01-01 01:00:00.0 +0100 +++ libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch 2024-01-06 08:23:50.0 +0100 @@ -0,0 +1,27 @@ +From 5b068a6e73e96db512ca8c60a11d31c068a5375f Mon Sep 17 00:00:00 2001 +From: Olivier Gagnon +Date: Sun, 19 Nov 2023 13:47:25 -0500 +Subject: [PATCH] The url with 'www.' is a permanent redirect (308) to the url + without it + +Signed-off-by: Mike Gabriel +--- + libmateweather/weather-metar.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/libmateweather/weather-metar.c b/libmateweather/weather-metar.c +index 0ae2cbb..7bc24fc 100644 +--- a/libmateweather/weather-metar.c b/libmateweather/weather-metar.c +@@ -550,7 +550,7 @@ metar_start_open (WeatherInfo *info) + } + + msg = soup_form_request_new ( +-"GET", "https://www.aviationweather.gov/cgi-bin/data/dataserver.php;, ++"GET", "https://aviationweather.gov/cgi-bin/data/dataserver.php;, + "dataSource", "metars", + "requestType", "retrieve", + "format", "xml", +-- +2.39.2 + diff -Nru libmateweather-1.26.0/debian/patches/series libmateweather-1.26.0/debian/patches/series --- libmateweather-1.26.0/debian/patches/series 2023-10-31 08:17:48.0 +0100 +++ libmateweather-1.26.0/debian/patches/series 2024-01-06 08:25:04.0 +0100 @@ -2,5 +2,6 @@ 0002_add-San-Miguel-de-Tucuman-Argentina.patch 0003_Chicago-area-updates.patch 0004_data-server-url-changed.patch +0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch 0005_fix-some-location-names.patch 0006_tbilisi-IATA-airport-code-changed.patch
Processed: bullseye-pu: package libmateweather/1.24.1-1+deb11u1
Processing control commands: > affects -1 + src:libmateweather Bug #1060130 [release.debian.org] bullseye-pu: package libmateweather/1.24.1-1+deb11u1 Added indication that 1060130 affects src:libmateweather -- 1060130: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060130 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve, On 05-01-2024 17:36, Rene Engelhard wrote: Also a problem is that experimental also might already contain totally unrelated updates like new upstream versions... I share this worry. Have you thought about how to handle the cases where you don't have experimental to upload to? How big is this problem? Another worry, how will you provide the required changes to the maintainers of the packages? Via BTS? For those working on salsa: MR? Both? Something else? Obviously we should not end in the situation that a new upload goes back to the old name (or are the ftp-masters so keen on this transition that that won't happen? But what about newer versions with the old name already in experimental, conform the former worry?). I've seen NMU's being ignored by subsequent uploads by the maintainer, even when they fixed RC issues which were then reintroduced. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: Re: Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Processing control commands: > tags -1 pending Bug #971739 [release.debian.org] release.debian.org: britney thinks ghostscript B-D on libz-dev:native is unsatisfiable Added tag(s) pending. -- 971739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971739 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Processing control commands: > tags -1 pending Bug #1059929 [release.debian.org] release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency Added tag(s) pending. -- 1059929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059929 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Control: tags -1 pending Hi, On 03-01-2024 20:40, Paul Gevers wrote: On 03-01-2024 20:22, Simon McVittie wrote: I think all of those are correct? I think that if apt allows you to install it, chances are that it's a britney2 bug. I'll try to debug it tomorrow. I have a first proposal for a fix in https://salsa.debian.org/release-team/britney2/-/merge_requests/89 Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059358: marked as done (transition: wolfssl)
Your message dated Fri, 5 Jan 2024 22:13:47 +0100 with message-id and subject line Re: Bug#1059358: transition: wolfssl has caused the Debian Bug report #1059358, regarding transition: wolfssl 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.) -- 1059358: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059358 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Control: affects -1 wolfssl X-Debbugs-Cc: wolf...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Control: forwarded -1 https://release.debian.org/transitions/html/auto-wolfssl.html wolfssl is available in experimental with libwolfssl42. This transition is from libwolfssl41. The auto-generated Ben file is okay and all reverse dependencies build fine. --- End Message --- --- Begin Message --- On 2023-12-27 21:19:54 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi Bastian > > On 2023-12-23 14:30:39 +0100, Bastian Germann wrote: > > Package: release.debian.org > > Control: affects -1 wolfssl > > X-Debbugs-Cc: wolf...@packages.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > Severity: normal > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-wolfssl.html > > > > wolfssl is available in experimental with libwolfssl42. > > This transition is from libwolfssl41. > > The auto-generated Ben file is okay and all reverse dependencies build fine. > > Please go ahead. The old binaries got removed. Cheers -- Sebastian Ramacher--- End Message ---
Bug#812155: marked as done (release.debian.org: Patch to make heidi output optional)
Your message dated Fri, 5 Jan 2024 22:30:14 +0100
with message-id <62c54826-144d-431d-b3c4-1ad05bf2b...@debian.org>
and subject line Re: release.debian.org: Patch to make heidi output optional
has caused the Debian Bug report #812155,
regarding release.debian.org: Patch to make heidi output optional
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.)
--
812155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812155
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: wishlist
Tags: patch
User: release.debian@packages.debian.org
Usertags: britney
Hi, I'm doing some work on britney as used by ubuntu and I've made Heidi output
optional as we were not using it in all cases, in the hopes of saving some
time/disk space.
Please consider the attached patch, thanks.
-- System Information:
Debian Release: stretch/sid
APT prefers xenial-updates
APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500,
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-5-generic (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
=== modified file 'britney.py'
--- britney.py 2016-01-19 20:05:32 +
+++ britney.py 2016-01-20 02:17:12 +
@@ -453,7 +453,7 @@
not getattr(self.options, k.lower()):
setattr(self.options, k.lower(), v)
-if not hasattr(self.options, "heidi_delta_output"):
+if self.options.heidi_output and not hasattr(self.options, "heidi_delta_output"):
self.options.heidi_delta_output = self.options.heidi_output + "Delta"
self.options.nobreakall_arches = self.options.nobreakall_arches.split()
@@ -3023,14 +3023,15 @@
except AttributeError:
self.write_dates(self.options.testing, self.dates)
-# write HeidiResult
-self.__log("Writing Heidi results to %s" % self.options.heidi_output)
-write_heidi(self.options.heidi_output, self.sources["testing"],
-self.binaries["testing"])
+if self.options.heidi_output:
+# write HeidiResult
+self.__log("Writing Heidi results to %s" % self.options.heidi_output)
+write_heidi(self.options.heidi_output, self.sources["testing"],
+self.binaries["testing"])
-self.__log("Writing delta to %s" % self.options.heidi_delta_output)
-write_heidi_delta(self.options.heidi_delta_output,
- self.all_selected)
+self.__log("Writing delta to %s" % self.options.heidi_delta_output)
+write_heidi_delta(self.options.heidi_delta_output,
+ self.all_selected)
self.printuninstchange()
--- End Message ---
--- Begin Message ---
HI,
On Wed, 20 Jan 2016 18:52:31 -0800 Robert Bruce Park
wrote:
Hi, I'm doing some work on britney as used by ubuntu and I've made Heidi output
optional as we were not using it in all cases, in the hopes of saving some
time/disk space.
Please consider the attached patch, thanks.
This was committed in commit 4907d5467c
Thanks
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
Bug#1060103: transition: imagemagick7
Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: ftpmas...@debian.org Imagemagick will need a new major bump I achieved to get imagemagick 7 build for experimental (it is only on salsa not uploaded yet). Every package include a version in the package name (except legacy package name and perl*) so I plan to do some step by step migration, because it is mainly coinstallable with imagemagick 6. - upload to experimental a version with perl and without legacy name - migrate perl and versioned package - add to experimental libmakickgwand-dev libmagick++-dev libmagickcore-dev - migrate package that depends on libmakickgwand-dev libmagick++-dev libmagickcore-dev (every thing that build against imagemagick) to imagemagick7 - add to experimental imagemagick package - migrate imagemagick package to unstable What do you think of this plan ? From a security point of view it is better to go to imagemagick7 (so important severity) I expect breakage only on the last step. See https://imagemagick.org/script/porting.php ftpmaster it need more work because it will need three manual step. Bastien * perlmagick, libmagickcore-dev, libmakickgwand-dev libmagick++-dev, imagemagick, libimage-magick-perl libimage-magick-q16-perl libimage- magick-q16hdri-perl signature.asc Description: This is a digitally signed message part.
Bug#1057304: marked as done (nmu: ros2-performance-test-fixture_0.2.0-1)
Your message dated Fri, 5 Jan 2024 22:16:44 +0100 with message-id and subject line Re: Bug#1057304: nmu: ros2-performance-test-fixture_0.2.0-1 has caused the Debian Bug report #1057304, regarding nmu: ros2-performance-test-fixture_0.2.0-1 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.) -- 1057304: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057304 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: binnmu X-Debbugs-Cc: ros2-performance-test-fixt...@packages.debian.org, team+robot...@tracker.debian.org Control: affects -1 + src:ros2-performance-test-fixture -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 nmu ros2-performance-test-fixture_0.2.0-1 . ANY . unstable . -m "Rebuild against benchmark (Closes: #1054676)" benchmark 1.8.3 apparently dropped an exported symbol, which causes an undefined reference to `benchmark::internal::Benchmark::Benchmark(char const*)' when linking against ros2-performance-test-fixture. A binNMU seems to be the simplest fix for that. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVruXkACgkQ+C8H+466 LVn5WAv/WyQ9BfZxjG9e6vDx2lGKvkTUSE0WnZ/V2wvwZXn1qytJDdKlsRuMuGTZ 9BE5usD35IKv2yuPnPjYNxB8cRfKZX2O5iDTVNf3WZ9puRpe7X5f2ydQevfsW7j0 foq+VZ5/dkWyNHskrOUXCZHewI59XNkrILgpRIel6A3aa0Nb13d6pn00775df244 zSrgB9eGzLH9fbZNI4TE63/re/CJAWBjS316qO5og7aAimELHldhxK2/RP+mZ2Av O0BGXl9d6j69L8CvpG0mSSH1iQ9ucbANM/4eUB5dKHMv24dLw+WV24Cy2J67scta B2ZJCnlSnxQ2l+MNCLPtakPHURuqEdDhMsVld3vcSiR6OawfAtG9v5W5AdVwGFRs abBLuUd+UaVS4zFBzQMKGoPXvvD5NVZWjj53Et5QziF37HkHuf9uw+V0MeVrNUfu 8ZiuOgk+BXZ2bF/oplASBqkr8aqtVWBMXkON15UXSrKLoUnL0Fmwk0HUL2B7fByH mX/9FT/J =g67D -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On 2023-12-03 10:45:38 +0100, Sebastian Ramacher wrote: > Control: tags -1 moreinfo > > On 2023-12-03 00:10:52 +0100, Timo Röhling wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > X-Debbugs-Cc: ros2-performance-test-fixt...@packages.debian.org, > > team+robot...@tracker.debian.org > > Control: affects -1 + src:ros2-performance-test-fixture > > > > nmu ros2-performance-test-fixture_0.2.0-1 . ANY . unstable . -m "Rebuild > > against benchmark (Closes: #1054676)" > > > > benchmark 1.8.3 apparently dropped an exported symbol, which causes an > > undefined reference to `benchmark::internal::Benchmark::Benchmark(char > > const*)' when linking against ros2-performance-test-fixture. > > If benchmark drops a symbol from its shared library without a SONAME > bump, that's a serious bug in benchmark. Please clarify the situation > with the benchmark maintainers. > > > A binNMU seems to be the simplest fix for that. > > That would just hide a serious bug in benchmark. benchmark got fixed. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi, Thanks for reaching out. On 05-01-2024 07:45, Johannes Schauer Marin Rodrigues wrote: It would generate the following two stubs (shortened here for brevity): Package: pkga Version: 1 Architecture: amd64 Depends: pkgc:any Multi-Arch: no Package: pkgb Version: 1 Architecture: amd64 Provides: pkgc Multi-Arch: allowed For britney2, the Sources stanza would also be needed; then we could use this to generate britney2 testcases. I created 10 of those yesterday by hand [1]. The simplest for of tests is a tree with var/data/unstable/Sources # i386 is the default archive of the testsuite, which can be overruled # if that makes sense var/data/unstable/Packages_i386 var/data/testing/Sources (may be empty) var/data/testing/Packages_i386 expected expected is in Heidi format (if I understand correctly) of what britney2 will allow to be in testing after the run, it will only migrate packages that are installable. Would it make sense to you to generate a branch in that archive with a bunch of tests that you know the answer too? Paul [1] https://salsa.debian.org/debian/britney2-tests/-/commit/5ab98de685e15a654227e9b188a48e44857f9d11 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059026: marked as done (transition: rocksdb)
Your message dated Fri, 5 Jan 2024 22:14:30 +0100 with message-id and subject line Re: Bug#1059026: transition: rocksdb has caused the Debian Bug report #1059026, regarding transition: rocksdb 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.) -- 1059026: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059026 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 Control: affects -1 + src:rocksdb Hi RMs, Small transition of RocksDB to the 8.9.1 release, available from experimental. Affected packages are balboa, oxigraph and sortmerna. While oxigraph is Sid only currently, all three build fine with this version of RocksDB as well. Thanks for considering, Laszlo/GCS --- End Message --- --- Begin Message --- On 2023-12-20 23:32:04 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi > > On 2023-12-19 14:31:20 +0100, László Böszörményi wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: affects -1 + src:rocksdb > > > > Hi RMs, > > > > Small transition of RocksDB to the 8.9.1 release, available from > > experimental. Affected packages are balboa, oxigraph and sortmerna. > > While oxigraph is Sid only currently, all three build fine with this > > version of RocksDB as well. > > Please go ahead. The old binaries got removed. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1059597: marked as done (transition: papi)
Your message dated Fri, 5 Jan 2024 22:14:58 +0100 with message-id and subject line Re: Bug#1059597: transition: papi has caused the Debian Bug report #1059597, regarding transition: papi 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.) -- 1059597: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059597 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 I'd like to update papi from libpapi7.0 to libpapi7.1. Only starpu needs a binNMU (builds fine locally). I'll upload a binNMU of starpu-contrib myself since it cannot be autobuilt due to the non-free nvidia-cuda-tookit build-dependency. https://release.debian.org/transitions/html/auto-papi.html Ben file: title = "papi"; is_affected = .depends ~ "libpapi7.0" | .depends ~ "libpapi7.1"; is_good = .depends ~ "libpapi7.1"; is_bad = .depends ~ "libpapi7.0"; Andreas --- End Message --- --- Begin Message --- On 2023-12-29 21:20:51 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi Andreas > > On 2023-12-29 01:51:37 +0100, Andreas Beckmann wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > I'd like to update papi from libpapi7.0 to libpapi7.1. > > Only starpu needs a binNMU (builds fine locally). > > I'll upload a binNMU of starpu-contrib myself since it cannot be > > autobuilt due to the non-free nvidia-cuda-tookit build-dependency. > > Please go ahead. The old binaries got removed. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition. Then, starting on Jan 18:
> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags
> I think at that point in time one should know what breaks and whatnot.
> Archive rebuild?
> (Probably in stages)
What kind of breakage are you looking to avoid here? As mentioned in other
points in the thread, regressions as a result of this change should be rare
and easy to fix. I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.
> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
> I get that you probably want NMUs for not needing to ping every maintainer,
> but this is bad.
> That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> when tagged end of next week to not have this caught in the transition. (see
> also below for the comment about new upstream versions in experimental.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
> >experimental with the new binary package names in order to clear binary
> >NEW, in coordination
> And what about skipped ones? When will those be tried?
What do you mean here by "skipped ones"?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
Bug#1060122: bookworm-pu: package atril/1.26.0-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: at...@packages.debian.org
Control: affects -1 + src:atril
While preparing a new upstream release upload of atril 1.26.1-1 to
unstable (already some days ago), a bookwork-pu upload has (now) also
been prepared.
[ Reason ]
Upstream fixed two issues regarding epub file opening robustness in
v1.26.1. Also, one patch could be cherry-picked from a bug report in
Debian BTS (#972715).
Additionally, the 'Hide sidebar' button was lacking a11y text which has
also now been added.
[ Impact ]
Impact of rejecting this bookworm-pu is low. Outcome: Less epub
robustness, a11y text for 'Hide sidebar' remains missing.
[ Tests ]
Manually (build and test on local bookworm system).
[ Risks ]
Regressions are always possible. Atril is used as PDF reader in MATE and
Xfce4, so those users will be affected.
[ 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 ]
+ * debian/patches:
++ Add 1002-avoid-crash-on-certain-epub-files.patch. Avoid crashes when
+ opening certain epub files. (Closes: #972715).
++ Add 0001-Accessibility-add-button-description.patch. Accessibility: add
+ 'Hide sidebar' button description. (Cherry-picked from v1.26.1).
++ Add 0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch. Fix
+ index loading for certain epub documents. (Cherry-picked from v1.26.1).
++ Add 0004-epub-add-fallback-for-malformed-epub-files-in-check_.patch.
epub:
+ add fallback for malformed epub files in check_mime_type. (Cherry-picked
from
+ v1.26.1).
[ Other info ]
None.
diff -Nru atril-1.26.0/debian/changelog atril-1.26.0/debian/changelog
--- atril-1.26.0/debian/changelog 2022-10-27 11:00:10.0 +0200
+++ atril-1.26.0/debian/changelog 2024-01-06 07:18:28.0 +0100
@@ -1,3 +1,18 @@
+atril (1.26.0-2+deb12u1) bookworm; urgency=medium
+
+ * debian/patches:
++ Add 1002-avoid-crash-on-certain-epub-files.patch. Avoid crashes when
+ opening certain epub files. (Closes: #972715).
++ Add 0001-Accessibility-add-button-description.patch. Accessibility: add
+ 'Hide sidebar' button description. (Cherry-picked from v1.26.1).
++ Add 0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch. Fix
+ index loading for certain epub documents. (Cherry-picked from v1.26.1).
++ Add 0004-epub-add-fallback-for-malformed-epub-files-in-check_.patch.
epub:
+ add fallback for malformed epub files in check_mime_type. (Cherry-picked
from
+ v1.26.1).
+
+ -- Mike Gabriel Sat, 06 Jan 2024 07:18:28 +0100
+
atril (1.26.0-2) unstable; urgency=medium
[ Mike Gabriel ]
diff -Nru
atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch
atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch
--- atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch
1970-01-01 01:00:00.0 +0100
+++ atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch
2024-01-06 07:18:28.0 +0100
@@ -0,0 +1,47 @@
+From 9a981607b36488ea5d2ce8646540b1545e35ecd5 Mon Sep 17 00:00:00 2001
+From: Valentin Villenave
+Date: Tue, 26 Oct 2021 19:29:01 +0200
+Subject: [PATCH 01/10] Accessibility: add button description
+
+Signed-off-by: Mike Gabriel
+---
+ po/POTFILES.in | 1 +
+ shell/ev-sidebar.c | 3 +++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/po/POTFILES.in b/po/POTFILES.in
+index 02b9435..08ab5ec 100644
+--- a/po/POTFILES.in
b/po/POTFILES.in
+@@ -67,6 +67,7 @@ shell/ev-password-view.c
+ shell/ev-properties-dialog.c
+ shell/ev-properties-fonts.c
+ shell/ev-properties-license.c
++shell/ev-sidebar.c
+ shell/ev-sidebar-annotations.c
+ shell/ev-sidebar-attachments.c
+ shell/ev-sidebar-bookmarks.c
+diff --git a/shell/ev-sidebar.c b/shell/ev-sidebar.c
+index b9173cd..0cdb6be 100644
+--- a/shell/ev-sidebar.c
b/shell/ev-sidebar.c
+@@ -26,6 +26,8 @@
+
+ #include
+
++#include
++#include
+ #include
+ #include
+
+@@ -362,6 +364,7 @@ ev_sidebar_init (EvSidebar *ev_sidebar)
+ g_signal_connect (close_button, "clicked",
+ G_CALLBACK (ev_sidebar_close_clicked_cb),
+ ev_sidebar);
++ gtk_widget_set_tooltip_text (close_button, _("Hide sidebar"));
+
+ image = gtk_image_new_from_icon_name ("window-close",
+ GTK_ICON_SIZE_MENU);
+--
+2.39.2
+
diff -Nru
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
---
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
1970-01-01
Processed: bookworm-pu: package atril/1.26.0-2+deb12u1
Processing control commands: > affects -1 + src:atril Bug #1060122 [release.debian.org] bookworm-pu: package atril/1.26.0-2+deb12u1 Added indication that 1060122 affects src:atril -- 1060122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060122 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Quoting Paul Gevers (2024-01-05 20:15:22) > Thanks for reaching out. Thank Helmut for poking me in #debian-apt :) > For britney2, the Sources stanza would also be needed; then we could use this > to generate britney2 testcases. I created 10 of those yesterday by hand [1]. > > The simplest for of tests is a tree with > var/data/unstable/Sources > # i386 is the default archive of the testsuite, which can be overruled > # if that makes sense > var/data/unstable/Packages_i386 > var/data/testing/Sources (may be empty) > var/data/testing/Packages_i386 > expected > > expected is in Heidi format (if I understand correctly) of what britney2 > will allow to be in testing after the run, it will only migrate packages > that are installable. > > Would it make sense to you to generate a branch in that archive with a bunch > of tests that you know the answer too? I think it's a bit more complicated than that. Currently, the tool creates 8624 package relationships. If I remember correctly, britney is unable to analyze cross-architecture relationships? In that case that number goes down to 2352. One could reduce that number even further and only check those cases where apt, dpkg and dose3 agree on a solution but that would then rather be a documentation of the status quo than a list of the intended ground truth. Maybe it would make sense to analyze the archive and only add those cases that currently exist as real package relationships? What the tool never received since its inception was somebody to look over these cases and write down what the ground-truth actually is supposed to look like. For the britney tests you likely want some kind of ground-truth and I fear that tool can give you the status quo but not necessarily the truth as intended by the spec. If that is fine for you, do you still want to add thousands of test-cases? Or do you want to hand-pick them? Thanks! cheers, josch signature.asc Description: signature
