Bug#973600: transition: gdal
On Tue, 8 Dec 2020 at 07:48, Sebastiaan Couwenberg wrote: > What should we do about r-cran-sf which cannot be built on most release > archs due to r-cran-s2 failing to build there (#976473). > > Should be file an RM bugreport to have r-cran-sf (and possible rdeps) > removed from those release architectures, or should it be hinted out of > testing? Well, first prize would be to fix r-cran-s2. Luckily, it seems to be already done upstream for arm64 [1], thanks to everyone's excitement about the Apple M1 silicon. I'll test and upload if successful. [1] https://github.com/r-spatial/s2/commit/76db560b9fe1b4dc4edbb6578fd1c132f130e820
Bug#976800: marked as done (nmu: libnewuoa_0.1.1-1)
Your message dated Tue, 8 Dec 2020 08:02:48 +0200 with message-id and subject line Re: Bug#976800: nmu: libnewuoa_0.1.1-1 has caused the Debian Bug report #976800, regarding nmu: libnewuoa_0.1.1-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.) -- 976800: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976800 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 Hello, I want to request binNMU on amd64 for recently accepted new package. nmu libnewuoa_0.1.1-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius --- End Message --- --- Begin Message --- On Tue, 8 Dec 2020 at 07:33, Andrius Merkys wrote: > nmu libnewuoa_0.1.1-1 . amd64 . unstable . -m "Rebuild on buildd" Scheduled, thanks.--- End Message ---
Bug#973600: transition: gdal
On 12/7/20 12:30 PM, Sebastiaan Couwenberg wrote: > On 12/6/20 12:37 PM, Sebastian Ramacher wrote: >> On 2020-11-02 12:49:04 +0100, Bas Couwenberg wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >>> Control: forwarded -1 >>> https://release.debian.org/transitions/html/auto-gdal.html >>> >>> For the Debian GIS team I'd like to transition to GDAL 3.2.0. >>> >>> All reverse dependencies rebuilt successfully with GDAL 3.2.0 from >>> experimental as summarized below, except mysql-workbench. >>> >>> libgdal-grass doesn't need a binNMU as the 3.2.0 version will be >>> uploaded to unstable instead. >> >> Please go ahead with the uploads to unstable. > > Thanks for quickly scheduling the binNMU even before it was installed on > all release architectures. > > Please also binNMU grass & postgis in experimental. What should we do about r-cran-sf which cannot be built on most release archs due to r-cran-s2 failing to build there (#976473). Should be file an RM bugreport to have r-cran-sf (and possible rdeps) removed from those release architectures, or should it be hinted out of testing? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#976800: nmu: libnewuoa_0.1.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, I want to request binNMU on amd64 for recently accepted new package. nmu libnewuoa_0.1.1-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius
Bug#900837: update on mass-rebuild of packages for reproducible builds
Hello Vagrant, On Fri, 4 Dec 2020 at 02:48, Vagrant Cascadian < vagr...@reproducible-builds.org> wrote: > On 2019-03-05, Holger Levsen wrote: > > I ran Chris's script again on coccia, with the result that currently > > 6084 source packages in the archive need a rebuild for reproducible > > builds, as they were built with an old dpkg version not producing > > .buildinfo files. > > I ran it just now, and we're down to 3433! Still a ways to go, but > getting there... > > Updated list attached. > That's great news, I'd like to help by making sure none of my packages are on this list, I can do the search myself but I'd like to ask for a list by maintainer name (if that's easy for you to generate). Mass bug filling would also help but I'm sure that was considered already. Thanks! -- Samuel Henrique
Processed: Re: Bug#976732: transition: rocksdb
Processing control commands: > tags -1 + confirmed Bug #976732 [release.debian.org] transition: rocksdb Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/auto-rocksdb.html Bug #976732 [release.debian.org] transition: rocksdb Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-rocksdb.html'. -- 976732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#976700: transition: wireshark ( late notice :-( )
Processing control commands: > tags -1 + confirmed Bug #976700 [release.debian.org] transition: wireshark ( late notice :-( ) Added tag(s) confirmed. -- 976700: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976700 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#976700: transition: wireshark ( late notice :-( )
Control: tags -1 + confirmed On 2020-12-07 08:04:58 +0100, Bálint Réczey wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I'm sorry, I missed that libvirt started shipping a wireshark plugin > and thus started depending on libwiresharkX in libvirt-wireshark. > > Please trigger rebuilds of libvirt in unstable, I have already > uploaded wireshark before noticing the reverse dependency. Libvirt > rebuilt for me locally with the new wireshark packages. Scheduled earlier today. Cheers > > Thank you, > Balint > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#976732: transition: rocksdb
Control: tags -1 + confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-rocksdb.html On 2020-12-07 15:20:48 +0100, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi RMs, > > Small transition of RocksDB from 5.17 to 6.11 which affects two > packages: balboa and vg. Both built fine with the new version of > RocksDB. Please go ahead. Cheers > > Thanks for consideration, > Laszlo/GCS > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#976423: buster-pu: package pngcheck/2.3.0-7
Hi David, On Fri, Dec 04, 2020 at 05:22:03PM -0500, David da Silva Polverari wrote: > Package: release.debian.org > Severity: important > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Hi, > > A global buffer overflow vulnerability was found by Red Hat on > pngcheck-2.4.0 [1]. It was found and reported by the Debian Security > Team that the vulnerability also affects the versions found on the > Debian archive [2]. > > The bug was already fixed on unstable [2]. I have prepared a revision > for buster-security for pngcheck/2.3.0-7 with the backported changes > from unstable. The proposed update builds correctly on a minimal > up-to-date buster chroot. > > I didn't coordinate with the security team, as the vulnerability is > marked "no-dsa" in the Debian Security Tracker [3]. > > If the update is deemed correct, I can make it available on mentors, and > open an RFS as I don't have uploading rights. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1902011 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976350 > [3] https://security-tracker.debian.org/tracker/CVE-2020-27818 > > Regards, > Polverari > diff -Nru pngcheck-2.3.0/debian/changelog pngcheck-2.3.0/debian/changelog > --- pngcheck-2.3.0/debian/changelog 2013-06-26 09:28:27.0 + > +++ pngcheck-2.3.0/debian/changelog 2020-12-04 21:22:18.0 + > @@ -1,3 +1,10 @@ > +pngcheck (2.3.0-7+deb10u1) buster-security; urgency=high For the update via the point release, the target distribution needs to be set to 'buster' (vs. buster-security). Regards, Salvatore
Release status of i386 for Bullseye and long term support for 3 years?
Dear release team Having participated in the current discussion about 32 bit releases and lifetimes in Linux Weekly News (lwn.net) - what's the status of i386 for the lifetime of Bullseye? There seems to be only one maintainer. Is i386 going to be supportable for the next 3 1/2 years and buildable for that long (given that almost all machines are now 64 bit capable and we're having to build some packages on amd64 for i386 - per ballombe)? Also asking because this came up over the weekend when working with the Debian Images team - no one has real UEFI hardware for i386 and it's becoming harder and hader to justify spending too much time on testing of the images as fewer and fewer machines can benefit from them. What are your thoughts, collectively? [I did ask one of you as an individual but he suggested respectfully and correctly that I should ask you all - thanks to him for the polite response]. All the very best to you all and with thanks, as ever, for all your work Andy C.
Bug#976352: transition: libjsoncpp
On Sat, 5 Dec 2020 12:33:47 +0100 Gianfranco Costamagna wrote: > After having a look at the failures, > two of them are gone with new d-shlibs > > Remaining are failing for unrelated stuff, or have patches: > > kopanocore fail (unrelated: #969297) > polybar fail (unrelated: #975795) > libseqlib fail (#976414) forwarded upstream that might be > easily patchable > mrptfail (#976420) forwarded upstream and its already > being worked on > open3d ok (might need one additional build deps due to new > qt) > spring fail (#976452 with patch) > springlobby fail (#976451 with patch) > vtk6fail (unrelated: #976424 with patch) mrpt, vtk6, open3d looks ok now remaining failures: kopanocore fail (unrelated: #969297) polybar fail (unrelated: #975795) libseqlib fail (#976414) forwarded upstream that might be easily patchable spring fail (#976452 with patch) springlobby fail (#976451 with patch) G.
Bug#976732: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi RMs, Small transition of RocksDB from 5.17 to 6.11 which affects two packages: balboa and vg. Both built fine with the new version of RocksDB. Thanks for consideration, Laszlo/GCS
Re: Porter roll call for Debian Bullseye
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote: > On 12/1/20 5:02 AM, YunQiang Su wrote: > > I am sorry for the later response. > >Hi, > > > > I am an active porter for the following architectures and I intend > > to continue this for the lifetime of the Bullseye release (est. end > > of 2024): > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in > testing ... The main blocker for that seems to be a bug that was fixed in gcc-10 10.2.0-20, a new source upload with the gcc-10-source build dependency bumped to (>= 10.2.0-20~) should fix that. binNMU won't work due to binary-all. > > - triage arch-specific bugs > > - fix arch-related bugs > > any help with #972269 ? I looked into it back then, at least for me there was nothing obvious why dbus-python failed and not other packages. A few months earlier one other package had a similar problem, but it seems rare enough that it shouldn't be a high priority for anyone. cu Adrian
Bug#973600: transition: gdal
On 12/6/20 12:37 PM, Sebastian Ramacher wrote: > On 2020-11-02 12:49:04 +0100, Bas Couwenberg wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org >> Control: forwarded -1 >> https://release.debian.org/transitions/html/auto-gdal.html >> >> For the Debian GIS team I'd like to transition to GDAL 3.2.0. >> >> All reverse dependencies rebuilt successfully with GDAL 3.2.0 from >> experimental as summarized below, except mysql-workbench. >> >> libgdal-grass doesn't need a binNMU as the 3.2.0 version will be >> uploaded to unstable instead. > > Please go ahead with the uploads to unstable. Thanks for quickly scheduling the binNMU even before it was installed on all release architectures. Please also binNMU grass & postgis in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#973480: transition: llvm-defaults
Hello, Le 04/12/2020 à 18:44, Sebastian Ramacher a écrit : Control: tags -1 + confirmed On 2020-10-31 14:35:36 +0100, Sylvestre Ledru wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, One more time, it is time to have upgrade llvm. I would like to ship bullseye with 11 and skip -10 (it had some performance regression in the binary generated). I am building a version with the ppc64el fix. llvm-defaults has been pointing to 11 in experimental for quite sometime. Happy to upload it in unstable when you give me the go. Rust already relies on -11 in experimental. Please go ahead. Thanks! Gianfranco uploaded it in unstable! Thanks S
Bug#971571: transition: libgit2
Hi Peter,
On Sun, Dec 6, 2020 at 11:06 AM peter green wrote:
> In addition to the packages mentioned here, it seems there is another
> package involved: golang-gopkg-libgit2-git2go.v28 . It only builds
> arch-all packages and does not directly depend on the library, but it
> FTBFS and it's autopkgtest fails with the new version.
>
> The FTBFS was picked up in a rebuild test by Lucas and a bug report
> was filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976522
Yes, because v28 is only compatible with libgit2 v0.28. For libgit2
v1.0, we need v30 for git2go. So I've uploaded
golang-gopkg-libgit2-git2go.v30 to NEW and once accepted, I'll file an
RM for v28.
The only reverse-{,build-}dependency is gitaly, it seems. So I'm CCing
Praveen so he gets a heads up.
