Bug#931551: transition: llvm-defaults to 8
Hi, On Sun, Jul 07, 2019 at 04:29:31PM +0200, Sylvestre Ledru wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hello > > Now that we release buster, I would like to move llvm-defaults to > llvm-toolchain-8. > > Thanks, > Sylvestre > > Ben file: > > title = "llvm-defaults"; > > Affected: .depends ~ /(clang|llvm)1?-?[345678]/ > Good: .depends ~ /(clang|llvm)1?-?[8]/ > Bad: .depends ~ /(clang|llvm)1?-?[34567]/ > I recently package ccls, which depends on libllvm[1]. I'm curious why this ben file doesn't include libllvm? And should I rebuild ccls manually? Or it will be handled by RT. I don't see ccls is on [2]. [1] https://tracker.debian.org/pkg/ccls [2] https://release.debian.org/transitions/html/llvm-defaults.html Thanks Shengjing Zhu signature.asc Description: PGP signature
Bug#931950: transition: libgeotiff
On Sun, 2019-09-15 at 08:27 +0200, Sebastiaan Couwenberg wrote: > On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote: > > libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) > > cannot > > be removed from testing due to gnudatalanguage, which I don't > > understand. But this should be resolved when the package get > > autoremoved > > on the 14th. > > gnudatalanguage was not removed yesterday, it's still marked for > removal on 14 September. It was removed in the 10:00 run on the 15th, which was the first run after it was in the auto-removals hint list. You just need a little more patience. > Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in > testing, Not any longer. Regards, Adam
Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream
Package: release.debian.org User: release.debian@packages.debian.org Usertags: rm The newer versions of the minetest game have better than what it provides It's abandoned upstream. This package has no rdeps. I'm the package maintainer (within the Debian Games Team), and I'm proposing to drop it off Debian testing (and unstable, with another bug report). JP
Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream
Control: tags -1 moreinfo Hi Julien, On 15-09-2019 13:16, Julien Puydt wrote: > I'm the package maintainer (within the Debian Games Team), and I'm > proposing to drop it off Debian testing (and unstable, with another bug > report). Did you already file that bug? Than we can close this bug as testing follows unstable automatically. If you haven't filed the bug, we can reassign it to ftp.debian.org. Paul
Processed: Re: Bug#940300: RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream
Processing control commands: > tags -1 moreinfo Bug #940300 [release.debian.org] RM: minetest-mod-torches -- RoM; obsolete and abandoned upstream Added tag(s) moreinfo. -- 940300: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940300 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#931950: marked as done (transition: libgeotiff)
Your message dated Sun, 15 Sep 2019 20:45:17 +0200 with message-id and subject line Re: Bug#931950: transition: libgeotiff has caused the Debian Bug report #931950, regarding transition: libgeotiff 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.) -- 931950: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931950 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: block -1 by 931949 For the Debian GIS team I'd like to transition to libgeotiff 1.5. This version is required for PROJ 6 support. This transition goes hand in hand with the proj transition. (#931949) All reverse depenencies built successfully with the new libgeotiff, only xastir & metview need to apply a patch to not FTBFS with PROJ 6. A summary of the rebuilds is included below. Ben file: title = "libgeotiff"; is_affected = .depends ~ "libgeotiff2" | .depends ~ "libgeotiff5"; is_good = .depends ~ "libgeotiff5"; is_bad = .depends ~ "libgeotiff2"; Transition: libgeotiff libgeotiff2 (1.4.3-1) -> libgeotiff5 (1.5.1-1~exp3) The status of the most recent rebuilds is as follows. libgeotiff-dfsg (1.4.3-1) SKIP (obsolete) libgeotiff-epsg (1.4.3-1) SKIP (obsolete) gdal(2.4.2+dfsg-1) OK gnudatalanguage (0.9.9-9) OK grads (3:2.2.1-1)OK librasterlite2 (1.1.0~beta0+really1.0.0~rc0+devel1-2) OK libterralib (4.3.0+dfsg.2-11) OK ossim (2.6.2-1) OK liblas (1.8.1-10) OK magics++(3.3.1-1) OK otb (6.6.1+dfsg-1) OK pdal(1.8.0+ds-1) OK xastir (2.1.0-5) OK [+] grass (7.6.1-1) OK metview (5.3.0-2) OK [+] Kind Regards, Bas --- End Message --- --- Begin Message --- On 9/15/19 12:42 PM, Adam D. Barratt wrote: > On Sun, 2019-09-15 at 08:27 +0200, Sebastiaan Couwenberg wrote: >> On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote: >>> libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) >>> cannot >>> be removed from testing due to gnudatalanguage, which I don't >>> understand. But this should be resolved when the package get >>> autoremoved >>> on the 14th. >> >> gnudatalanguage was not removed yesterday, it's still marked for >> removal on 14 September. > > It was removed in the 10:00 run on the 15th, which was the first run > after it was in the auto-removals hint list. You just need a little > more patience. Thanks for the clarification. It seems that to me that autoremovals take more time than before, but I may just be imagining that. >> Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in >> testing, > > Not any longer. libgeotiff-dfsg is not in testing any more either. Considering this transition completed. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1--- End Message ---
Bug#939048: marked as done (transition: glibc)
Your message dated Sun, 15 Sep 2019 21:18:41 +0200 with message-id <2f71052f-e97d-b9bd-5102-17e716c08...@debian.org> and subject line Re: Bug#939048: transition: glibc has caused the Debian Bug report #939048, regarding transition: glibc 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.) -- 939048: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939048 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 get a transition slot for glibc 2.29. It is available in experimental for a bit more than 2 weeks and there is no known issue or regression. It has been built successfully on all release architectures and most ports architectures. It fails to build on alpha, ia64 and sparc64 due to a few testsuite issues that are being investigated or need to be investigated and which do not looks really worrying. It doesn't build on kfreebsd-*, but this has been the case for a few glibc releases already. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition (some packages only on some architectures): - apitrace - bro - dante - gcc-9 - gcc-snapshot - glibc - libnih - libnss-db - unscd Ben file: Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(<--- End Message --- --- Begin Message --- On Sun, 8 Sep 2019 22:39:20 +0200 Aurelien Jarno wrote: > On 2019-09-08 22:23, Paul Gevers wrote: > > Control: tags -1 confirmed > > > > Hi Aurelien, > > > > Let's have this going. > > Ok, I have just uploaded it. It's all finished now, closing. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Processed: transition: libgweather
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-libgweather.html Bug #940350 [release.debian.org] transition: libgweather Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libgweather.html'. -- 940350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940350 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#940350: transition: libgweather
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libgweather.html Dear release team, I'm requesting a transition slot for libgweather on behalf of the Debian GNOME Team. >From libgweather NEWS: > This version of the library bumps the soname after an ABI break in 3.28.0 > that went unnoticed. If you see strange crashes, make sure to bump the > required version of libgweather to 3.28.0 or newer. In other words we should already be affected by the "new" ABI/API and no issues should arise. This transition is mainly to get the new version into unstable and sync SONAME with upstream. For avoidance of doubt I went ahead and did a rebuild of all reverse dependencies anyway and no issues where spotted. (For anyone interested the build logs temporarily available at: http://fatal.se/tmp/libgweather3.33.92/build-logs/ .. as attaching them did not work because of size.) Ben file: title = "libgweather"; is_affected = .depends ~ "libgweather-3-15" | .depends ~ "libgweather-3-16"; is_good = .depends ~ "libgweather-3-16"; is_bad = .depends ~ "libgweather-3-15"; Regards, Andreas Henriksson
Bug#933548: transition: gnome-desktop3
Control: tags -1 - moreinfo Dear release team, I've done rebuild tests of reverse dependencies for the gnome-desktop3 transition and the results are that there's one failure: budge-desktop (The build logs are temprorarily available from: https://fatal.se/tmp/gnome-desktop-3_3.34/build-logs/ ) It seems there's a version of budge-desktop prepared in experimental that adresses the problem. This transition should thus hopefully be in good shape and ready to go at any point when the release team have a slot free for it. Regards, Andreas Henriksson
Processed: Re: transition: gnome-desktop3
Processing control commands: > tags -1 - moreinfo Bug #933548 [release.debian.org] transition: gnome-desktop3 Removed tag(s) moreinfo. -- 933548: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933548 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#933577: transition: evolution-data-server
FWIW The blocker for the evolution-data-server transition already identified by Laney could possibly be handled by temporarily removing src:eweouz from testing as it doesn't seem to have any reverse (build-)dependencies. (A full rebuild of reverse dependencies might however be useful to make sure no new issues has appeared since this bug was originally filed.) Regards, Andreas Henriksson
Bug#940460: transition: mutter
Package: release.debian.org Severity: normal Tags: moreinfo User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 940161 933548 Control: forwarded -1 https://release.debian.org/transitions/html/auto-mutter.html Dear release team, I'm filing this bug report on behalf of the Debian Gnome Team to track the status of the upcoming mutter transition that's not yet quite ready to go (and thus tagged moreinfo). Depends: gsettings-desktop-schemas-dev (>= 3.33.0) - needs to be uploaded at the same time as mutter 3.34 Depends: libglib2.0-dev (>= 2.61.1) - upload to unstable tracked in https://bugs.debian.org/940161 Depends: libgnome-desktop-3-dev (>= 3.33.4) - transition tracked in https://bugs.debian.org/933548 Regards, Andreas Henriksson
Processed: transition: mutter
Processing control commands: > block -1 by 940161 933548 Bug #940460 [release.debian.org] transition: mutter 940460 was not blocked by any bugs. 940460 was not blocking any bugs. Added blocking bug(s) of 940460: 933548 and 940161 > forwarded -1 https://release.debian.org/transitions/html/auto-mutter.html Bug #940460 [release.debian.org] transition: mutter Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-mutter.html'. -- 940460: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940460 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#894663: transition: wxwidgets3.0
On 14.09.19 21:31, Scott Talbert wrote: > On Sat, 14 Sep 2019, Gunter Königsmann wrote: > >> * Scroll Wheels and Two-Finger scroll are broken in this >> combination, if >> Wayland is used (934386) and > > Is two finger scrolling really a high priority issue? It seems like a > nice to have rather than a must-have IMHO. > >> * If a horizontal scrollbar is visible all custom controls (e.G. >> wxMaxima's worksheet) flicker badly (934386) > > On this issue, I'm not convinced that upstream can reproduce it, based > on the comments in the ticket. I don't think that I've reproduced it > either. Since you claim that it doesn't occur with wx 3.1, can you do > a bisection between wx 3.0 and 3.1 to determine which commit fixed > it? If we can figure that out, we can backport the patches. > Vadim (who is one of the maintainers) can reproduce it. I cannot guarantee, though, if the right graphics card/GTK version/something else needs to be used in order to trigger the bug. Or if this is one of the esoteric bugs that only affect a handful of users. >> If wxMaxima otherwise would be dropped from debian I am willing to >> switch >> to a flickering version that uses GTK3. But if I don't occur this risk I >> would rather stay at GTK3 until wxGTK 3.2 is released - which will >> fix this >> issue. The wxWidgets maintainers told me that wxGTK 3.2 will be released >> "soon". But the same was true a year ago - which I normally would be >> fine >> with: wxGTK 3.1 works fine, the combination of wxGTK 3.0 and GTK2 works >> fine, too - and it is wise to release a library when it is ready, not >> according to an arbitrary schedule. > > Well, there is still time to fix the issues - Bullseye release is > still a long way off. > > And yes, upstream wx claims that wx 3.2 will be "soon" but we have > heard that for a long time. :) So I don't think we can depend on that. > That only partially answers my question. Currently I am playing with the thought if the right idea would be uploading a wxMaxima version that uses GTK3 to debian testing and looking if anyone except Vadim and me is affected by the bug. Kind regards, Gunter.
