Re: Severity bump script

Hi Ondrej, On 02-12-2019 20:33, Ondrej Novy wrote: > Hi, > > po 2. 12. 2019 v 20:28 odesílatel Paul Gevers <mailto:elb...@debian.org>> napsal: > > I understand the drive to push for Python 2 removal and sympathize with > it. The issue I had yesterday with the

Bug#944417: transition: cgal

Control: tags -1 moreinfo Hi Joachim, On 15-11-2019 17:27, Joachim Reichel wrote: > crrcsimneeds source code changes, patch available [...] > k3dneeds source code changes, patch available [...] > openscad needs source code changes, patch available > pgrouting needs source code chan

Re: Severity bump script

Hi, On 02-12-2019 22:15, Sandro Tosi wrote: > the blocks are only between py2removal packages, so if a package > un-related to the py2removal effort > depend/recomments/b-deps/autotest-triggers a py2removal *application*, that > is still considered a leaf package You'll fix that, right? Because w

Bug#944417: transition: cgal

Control: tags -1 confirmed Hi Joachim, On 03-12-2019 08:31, Joachim Reichel wrote: > I've contacted the maintainers on Nov. 11th about the upcoming transition and > included my patches, but did not file bugs so far. I suggest you file those bugs against the packages that you're not in contact al

Bug#944417: Bug#946119: binNMU for gudhi, openems, and pygalmesh

Hi Joachim, Note: there is no need to create a new bug report for binNMU's that are part of a transition with a transition bug. That said, mips64el and mipsel FTBFS, can you please check what's going on? On 04-12-2019 00:02, Joachim Reichel wrote: > please schedule binNMUs for gudhi, openems, an

Re: Severity bump script

Hi, On 03-12-2019 13:19, Matthias Klose wrote: > It's unfortunate that issues for some packages only get attention when the > severity of an issue is raised. Following your proposal means that the issue > is > probably ignored forever, and you don't propose a better way going forward, > just >

Bug#945983: transition: petsc

Hi Drew, On 02-12-2019 09:31, Drew Parsons wrote: > I'd like to proceed with the PETSc 3.12 transition. > > The MUMPS 5.2.1 is also ready to go, but I think it might be more > constructive to demonstrate via testing migration that the new petsc > is stable with the old mumps than to show the new

Bug#946281: transition: liblouis

Control: tags -1 confirmed Hi Samuel, On 06-12-2019 17:15, Samuel Thibault wrote: > Upstream of liblouis cleaned the library interface in version 3.12, > leading to a bump from liblouis19 to liblouis20. I am thus requesting > a transition slot. The only build rdeps are brltty, liblouisxml and > l

Re: Bug#944920: Revise terminology used to specify requirements

Dear Policy Editors, On 21-11-2019 13:59, Paul Gevers wrote: > [Disclaimer: the words below are as a member of the release team, but > not necessarily those of the team. We haven't discussed this yet.] We have had a discussion, and there were no objections against my vision belo

Bug#944417: transition: cgal

Control: tags -1 pending Hi all, cgal migrated to testing. The transition is finished after the autoremoval of k3d and rheolef in a couple of days, or when their fixed, whatever happens first. Paul signature.asc Description: OpenPGP digital signature

Bug#945983: transition: petsc

Control: tags -1 confirmed Hi Drew, On 05-12-2019 15:11, Drew Parsons wrote: > On 2019-12-05 20:22, Paul Gevers wrote: >> Hi Drew, >> >> On 02-12-2019 09:31, Drew Parsons wrote: >>> I'd like to proceed with the PETSc 3.12 transition. >>> >>>

Proposal on how to proceed with Python 2 removal from bullseye

Dear all, TL;DR: as the subject suggests, proposal included, although not fully aligned with others. On 08-12-2019 20:55, Sandro Tosi wrote: > there seems to be disagreement on how to proceed, so for the time > being i suspended the severity bump part of the py2removal tracking > script. let me k

Bug#945983: transition: petsc

Hi Drew, On 15-12-2019 07:07, Drew Parsons wrote: > Did I understand correctly you were in favour of lumping > the MUMPS transition in at the same time to get the stack updated all > together? Yes > In that case in the spirit of a package deal, I suggest > throwing in scalapack 2.1.0 as well. G

Re: possible bug in auto-removals.

Hi Peter, On 16-12-2019 01:21, peter green wrote: > I have been observing a number of python cruft packages that are still > in testing recently, and I noticed that there seems to be an issue with > an auto-removal. cruft has never been supposed to be in testing. There was a bug in britney that w

Bug#946918: transition: libcgns

Control: tags -1 confirmed Hi Gilles, > I'd like to transition libcgns 3.4.0 which has been staging into experimental > for more than a month. There are very few reverse depedencies: > * paraview > * code-saturne > and maybe gmsh which build-depends on libcgns-dev but has no binary package > depe

Bug#946918: transition: libcgns

Hi Gilles, On 17-12-2019 23:07, Gilles Filippini wrote: > Paul Gevers a écrit le 17/12/2019 à 22:31 : >>> I'd like to transition libcgns 3.4.0 which has been staging into >>> experimental >>> for more than a month. There are very few reverse depedencies: >&g

Bug#945983: transition: petsc

Hi Drew, On 20-12-2019 23:56, Drew Parsons wrote: > ga will need a binNMU for scalapack too. Scheduled. > To keep the static symbols consistent, nwchem should be rescheduled for > another binNMU once ga is rebuilt. Scheduled with an --extra-depends. Paul signature.asc Description: OpenPGP d

Re: possible bug in auto-removals.

Hi Peter, Thanks for your analysis. I believe I mostly came to same conclusion some days ago. Thanks for caring. On 21-12-2019 08:07, peter green wrote: > My understanding is that smooth updates is a feature that deliberately > allows some cruft in testing to make it easier for transitions to com

Bug#947161: transition: libwebsockets

Control: tags -1 confirmed Hi László, On 22-12-2019 10:53, László Böszörményi (GCS) wrote: > Small transition with four affected packages. Namely ddnet, > forked-daapd, janus and mosquitto. All build fine with the new > libwebsocket release in experimental. Please go ahead. Paul signature.as

Bug#947165: transition: llvm-defaults to 9

Control: tags -1 moreinfo Hi Sylvestre, On 22-12-2019 11:57, Sylvestre Ledru wrote: > LLVM 9.0.1 has just been released. I am not planning to spend significant > time on the -8 branch. > It is therefor time to move to the version 9 Just to get it clear, this is only switching the default from 8

Bug#947170: transition: botan

Control: tags -1 confirmed Hi László On 22-12-2019 13:42, László Böszörményi (GCS) wrote: > Small transition of botan, which is already in experimental. Two > packages are affected, namely biboumi and libqtshadowsocks. > The biboumi source builds fine with the new botan release. Please go ahead

Bug#947365: transition: libvigraimpex

Control: tags -1 confirmed Hi Andreas, On 25-12-2019 19:29, Andreas Metzler wrote: > libvigraimpex is marked for autoremoval because of the python2 removal. > This is fixed in experimental, the new version features a soname bump. > this should be a small scale transition. I have successfully [1]

Bug#947165: transition: llvm-defaults to 9

Hi Sylvestre, On 26-12-2019 22:18, Sylvestre Ledru wrote: >> Just to get it clear, this is only switching the default from 8 to 9, >> right? > And rebuild packages to depend on -9. Sure; for those that don't hard-code the version. >> What happens if rebuilt packages don't migrate to testing? I'

Bug#947165: transition: llvm-defaults to 9

Hi Sylvestre, On 27-12-2019 10:46, Sylvestre Ledru wrote: >> But rustc is having issues migrating, so this is something I am worried >> about. Also, do you understand why rust-bindgen and rust-clang-sys are >> mentioned in the tracker? I looked *briefly* but didn't spot the >> connection yet. > >

Bug#947397: transition: cppunit

Control: tags -1 moreinfo Hi Rene, On 26-12-2019 10:59, Rene Engelhard wrote: > Simple new (minor) upstream version. > > Most packages just build-depend on it. A rebuild using ratt just works, > except some totally unrelated failures: I'm not able to reliably parse this sentence. Can you please

Bug#947397: transition: cppunit

Hi Andreas, On 27-12-2019 22:37, Andreas Tille wrote: > Source upload of gatb-core done. Thanks for the quick response. Paul PS: @Rene, as gatb-core is a transition by itself, we'll proceed with cppunit after gatb-core migrates. signature.asc Description: OpenPGP digital signature

Bug#947676: RM: qt4-x11/4:4.8.7+dfsg-19

Hi Lisandro, Moritz, On 29-12-2019 11:26, Moritz Mühlenhoff wrote: >> Hi! As you know we are doing an effort to remove qt4-x11 from the archive. >> The >> next big step is removing it from testing. >> >> If my data is accurate the only package holding qt4-x11 in testing is scim, >> which I have j

Bug#947365: transition: libvigraimpex

Hi Andreas, On 27-12-2019 18:08, Andreas Metzler wrote: > On 2019-12-26 Paul Gevers wrote: >> On 25-12-2019 19:29, Andreas Metzler wrote: >>> libvigraimpex is marked for autoremoval because of the python2 removal. >>> This is fixed in experimental, the new ver

Bug#942428: transition: gssdp/gupnp

Hi Laurent, Andreas, On 30-12-2019 15:09, Laurent Bigonville wrote: > So apparently this was a bug in gupnp that was making the tests deadlock > and for some reasons the version fixing this was stuck in the armel > buildd... > > anyway, gupnp-igd is now building fine in experimental. Good. > I

Bug#942428: transition: gssdp/gupnp

Control: tags -1 - moreinfo Control: tags -1 confirmed Control: block -1 by 947805 Hi Laurent, Andreas, On 31-12-2019 01:20, Laurent Bigonville wrote: >> peony-extensions - no rdeps, unmaintained <--- temporary removal? >> not really, the package is >> ag

Bug#947397: transition: cppunit

Control: tags -1 - moreinfo Control: tags -1 confirmed On 28-12-2019 11:21, Paul Gevers wrote: > PS: @Rene, as gatb-core is a transition by itself, we'll proceed with > cppunit after gatb-core migrates. Rene, please go ahead. It looks like gatb-core is now the only reverse-dependency

Bug#947165: transition: llvm-defaults to 9

Control: tags -1 - moreinfo Hi, > They build-depend on llvm/clang, not sure whether they are actually part > of the transition. I worked a bit on the tracker page and I think it has a better view of what is involved (basically limiting "Affected" to the -dev packages from llvm-defaults). We cu

Bug#947365: transition: libvigraimpex

Hi Andreas, On 31-12-2019 18:26, Andreas Metzler wrote: > On 2019-12-31 Sebastiaan Couwenberg wrote: >> I would commit the change now, and upload it after the testing migration >> unless there are other blockers that hold up the migration for more than >> 5 days, then I would upload it now. > >

rust ecosystem worries of a release team member

Dear rust maintainers, I should have probably contacted you earlier, but better now than latter. I think it is time to align between the rust maintainers and the release team how we (ideally you without needing our assistance) can manage the rust stack in testing (and thus in unstable). The last

Bug#944227: marked as done (transition: prompt-toolkit)

Control: reopen -1 Hi Gordon, On 06-01-2020 16:39, Debian Bug Tracking System wrote: > Your message dated Mon, 06 Jan 2020 15:37:55 + > with message-id > and subject line Bug#944227: fixed in prompt-toolkit 2.0.10-2 > has caused the Debian Bug report #944227, > regarding transition: prompt-t

Bug#947885: transition: gecode

Control: tags -1 confirmed Hi Kari, On 01-01-2020 18:55, Kari Pahula wrote: > I'm about to update gecode from 6.1.0 to 6.2.0 in unstable. SONAME > changes from 48 to 49. > > The only reverse dependency is minizinc which I also maintain. > Transitively minizinc-ide as well. All of these have ha

Bug#939989: transition: gdal

Control: tags -1 confirmed Hi Sebastiaan, On 24-11-2019 08:44, Sebastiaan Couwenberg wrote: >> Once both networkx packages have migrated to testing we're good to go >> with the gdal transition. This happened yesterday. > Let's see what happens first: this, or the QGIS 3.10.4 release which > mak

Bug#948199: non-transition: libqt5quick5-gles

Hi Dmitry, On 08-01-2020 16:34, Dmitry Shachnev wrote: > The good rule is: .depends ~ "libqt5gui5-gles" > > However it should be: .depends ~ "libqt5quick5-gles", i.e. s/gui/quick/. > > After that much more packages should become bad. Good catch. Fixed. Paul signature.asc Description: OpenPG

Bug#948468: (unplanned) transition: gpsd

Control: tags -1 confirmed On 09-01-2020 01:14, Bernd Zeimetz wrote: > unfortunately gpsd upstream missed to change the soname version (seems > its actually mentioned in the commit message, but the change is missing) > and I also missed that one struct changed in a subtle way. Did I just failed t

Re: rust ecosystem worries of a release team member

Hi all, On 05-01-2020 14:39, Ximin Luo wrote: > Paul Gevers: >> [..] >> >> [1] Now thunderbird is blocked by rust-cbindgen (last version migrated >> in September with uploads since October), which is blocked by rust-syn >> (last version migrated in July, with ne

Bug#947979: Please add a tracker for the enchant -> enchant-2 transition

Control: tags -1 confirmed Dear Laurent, On 04-01-2020 01:10, Laurent Bigonville wrote: > Could you please add a tracker for the enchant -> enchant-2 "transition" Done. Slightly different from a regular transition: all involved packages need a source-full upload to switch and this can happen ove

Bug#939989: transition: gdal

Hi, On 11-01-2020 17:38, Sebastiaan Couwenberg wrote: > On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote: >> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote: >>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures. >>> >>> Please schedule the binNMUs. >> >> Thanks for scheduling

Bug#939989: transition: gdal

Hi Sebastiaan, On 12-01-2020 08:18, Sebastiaan Couwenberg wrote: >> Probably I am saying something stupid, but e.g. gdal-data () breaks >> libgdal* . I notice that the library already has a larger than >> relation on gdal-data, but apparently there should have been a smaller >> than relation as we

Bug#947165: transition: llvm-defaults to 9

Control: tags -1 confirmed Hi, On 03-01-2020 07:56, Paul Gevers wrote: > We currently have a bit much transitions going on (and some backslash > from a piuparts bug), so I'd like to get a bit of those transitions off > the table before starting this one. > > I'll le

Bug#948477: transition: openbabel

Control: tags -1 moreinfo Hi Andrius, On 09-01-2020 08:17, mer...@debian.org wrote: > I would like to request a transition slot for openbabel (experimental -> > unstable). Current ben tracker [1] is fine, it just misses avogadrolibs, > which has been recently accepted into unstable. Please elabo

Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1

Hi Michael, On 18-07-2020 11:51, Michael Tokarev wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > The package openhackware builds a single binary blob, ppc_rom.bin, > which is a bios/firmware for old PowerPC machines. > > T

Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1

Control: reassign -1 ftp.debian.org Hi Michael, On 28-07-2020 10:00, Michael Tokarev wrote: > 28.07.2020 10:53, Paul Gevers wrote: > .. >> These request should normally be filed against ftp.debian.org and the >> package should be removed from unstable first (and then it&

Re: Bug#968309: src:austin: fails to migrate to testing for too long: FTBFS on armhf and mipsel

Hi Gabriele, On 23-08-2020 17:07, Gabriele wrote: > I believe this migration issue is caused by the build failure of > Austin on a couple of architectures. Unfortunately, I do not have the > means to debug on such platforms and therefore I am unlikely to be > able to provide a fix. Austin is guara

Re: Go issues wrt. Debian infrastructure: moving forward

Hi, On 26-08-2020 13:40, Clément Hermann wrote: > On 26/08/2020 13:22, Reinhard Tartler wrote: >> >> >> On Wed, Aug 26, 2020 at 7:09 AM Bastian Blank > > wrote: >> >> Hi Clement >> >> On Wed, Aug 26, 2020 at 12:39:36PM +0200, Clément Hermann wrote: >> > - a way

Bug#969083: unblock: libomxil-bellagio/0.9.3-6

Hi Paul On 27-08-2020 13:22, Ying-Chun Liu (PaulLiu) wrote: > libomxil-bellagio0 can be a "plugin" of gst-omx. That means gst-omx can > be run by itself without libomxil-bellagio0 at all. > The problem happens in autopkgtest. In test, we use libomxil-bellagio0 > as a plugin to test gst-omx. So, t

Bug#969211: RM: redmine/4.0.7-1

Dear Pirate, On 29-08-2020 12:54, Pirate Praveen wrote: > redmine is not compatible with rails 6 (#969206). This is blocking > migration of rails 6 to testing. Please remove redmine from testing to > allow rails 6 to migrate to testing. That redmine bug was filed just before you requested the rem

Re: Bug#966114: src:cyrus-imapd: Mail::JMAPTalk version 0.15 required--this is only version 0.13 at ./Cassandane/Cyrus/JMAPCore.pm

Hi Chris, On 03-09-2020 18:12, Chris Hofstaedtler wrote: > * Xavier [200903 16:10]: >>> I must say I find it unacceptable that autopkgtests which are being >>> used to test migration from Debian unstable to Debian testing to rely >>> on code from random places on the Internet, which Debian Develo

Re: android-framework-23 autorm weirdness.

Hi Peter, On 05-09-2020 09:38, peter green wrote: > The tracker for android-framework-23 shows it as due for autoremoval > today (and IIRC has been saying that for some time) > , and indeed britney is trying to remove it but is failing to do so. > > Strangely the tracker for andriod-framework-23

Bug#970491: nmu: ghostscript_9.53.1~dfsg-1

Hi Jonas, On 17-09-2020 09:43, Jonas Smedegaard wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu ghostscript_9.53.1~dfsg-1 . ANY . unstable . -m "re-sync symlinks with > newer release of fonts-urw-base35" > > A new

Bug#970491: nmu: ghostscript_9.53.1~dfsg-1

Hi Jonas, On 17-09-2020 10:12, Jonas Smedegaard wrote: > Ghostscript package uses dh_linktree, which has this to say: ^^^ answers my question. >> Since symlink trees are created statically at build-time, they are not >> very future-proof and have a risk to miss

update on autopkgtest architecture coverage

Dear all, Recently I have been adding support for armhf and i386 on the ci.debian.net infrastructure. To avoid confusing, let me summarize the current state of affairs. # Archs ci.debian.net now supports the following architectures: amd64, arm64, armhf, i386 and ppc64el. amd64 is the oldest ar

Re: Request for advice on mariadb-10.5 migration schedule

Hi Otto, On 29-10-2020 16:28, Otto Kekäläinen wrote: > I kindly ask assistance from the Debian release team what to do about > MariaDB 10.5. I think it's good that you reach out. > I have been working on MariaDB 10.5 packaging since August[1] and I've > had it in unstable since early September[2

subjects for bits from the release team?

Hi, With just over two months to go before the first freeze for bullseye [1], I was thinking it's time for a bits from the release team. Does any of you have subjects they want to bring up? I'll start on a "generic" text soon (unless somebody else volunteers), but if there's anything you want to m

Bug#972278: transition: qtbase-opensource-src

Hi Dmitry, On 01-11-2020 15:19, Dmitry Shachnev wrote: > - libqglviewer test is called with the following trigger: > qtbase-opensource-src-gles/5.15.1+dfsg-2 qtbase-opensource-src/5.15.1+dfsg-2 > > However that package depends on libqt5opengl5-dev, for which we do not > provide a -gles vers

Bug#971415: transition: ocaml

HI Stéphane, On 02-11-2020 16:56, Stéphane Glondu wrote: >> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference >> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), >> i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻) > > However

Bug#959469: buster-pu: package openssl/1.1.1g-1

Hi Sebastian, On 15-11-2020 11:29, Sebastian Andrzej Siewior wrote: > The same error is also present in the stable version of swi-prolog. > However, this is not the only failure in the test suite (it also > complains about too small keys) and there is no debci for stable which > would cause a regr

Re: Request for advice on mariadb-10.5 migration schedule

Hi Otto, On 22-11-2020 14:11, Otto Kekäläinen wrote: >> Could you please add some whitelist/override for debci so that at >> least the issue of "autopkgtest for mariadb-10.3/1:10.3.24-2" failing >> would go away [...] > > I see you did this in https://release.debian.org/britney/hints/elbrus, than

Re: Request for advice on mariadb-10.5 migration schedule

Hi Otto, On 22-11-2020 14:41, Otto Kekäläinen wrote: > This is a temporary transitional package that does not exist in 10.5 > anymore: https://packages.debian.org/unstable/libmariadbclient-dev This is a binary from mariadb-10.3. We discussed before, it shouldn't be part of bullseye, right? What y

Re: Bug#972669: src:tarantool: fails to migrate to testing for too long: FTBFS on armhf and arm64

Hi Steve, Thanks for your feedback, CC-ing in the Release Team, because it's their policy [1]. On 26-11-2020 00:37, Steve Langasek wrote: > It seems quite counterintuitive that this bug would be marked as closed in > unstable, given that it's the unstable version which fails to build? Yes, I cou

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

Control: tags -1 moreinfo On 03-12-2020 19:01, Pirate Praveen wrote: > This package is blocking ruby-faraday 1.0 migration to testing > (#976343). Which is like, minutes old. > Its only reverse dependency is > ruby-diaspora-federation-rails, which in turn has only one other reverse > dependency

Bug#976344: RM: ruby-diaspora-federation/0.2.6-2

Control: tags -1 pending Hi Pirate, On 03-12-2020 19:20, Pirate Praveen wrote: > Are you saying we should not be proactively helping packages to migrate > to testing? What I'm saying is that it helps to include such details in the original request. Paul OpenPGP_signature Description: OpenPGP

Bug#976377: RM: sqlite/2.8.17-15, golang-gosqlite-dev/0.0~hg20130601-1

Control: tags -1 moreinfo Hi Simon, On 04-12-2020 11:10, Simon McVittie wrote: > Please mark golang-gosqlite-dev and sqlite for removal from testing. > sqlite version 2 has been unsupported since 2005 and its removal from > Debian was first proposed in 2010; golang-gosqlite-dev is the last > rema

Bug#900837: update on mass-rebuild of packages for reproducible builds

Hi Vagrant On 04-12-2020 03:46, Vagrant Cascadian 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 p

Re: New consul package not migrating to testing because of patroni autopkgtest?

Hi Reinhard, On 09-12-2020 20:21, Reinhard Tartler wrote: > Turns out that the test errors were transient and someone scheduled > retries for amd64 which passed. It seems we still have errors on arm64 > and I expect that to go away with some retries as well. > > I noticed that the arm64 build als

Re: Software RAID is not activated at boot time

Hi fellow Release team member, and Cyril specifically, On Fri, 29 Mar 2019 19:18:43 +0100 Ivo De Decker wrote: > On Thu, Jun 08, 2017 at 03:04:16PM +0200, Christoph Pleger wrote: > > dmraid in jessie currently does not activate my software raid. As the > > boot/root partition is on the raid, my m

Re: slurm-wlm transition to testing

Hi, On 11-12-2020 09:14, Sebastian Ramacher wrote: > On 2020-12-11 02:03:40 +0100, Gennaro Oliva wrote: >> the autopkgtest for the slurm-wlm package is failing on ppc64el because >> mariadb is not starting in the autopkgtest environment as you can see >> here: >> >> https://ci.debian.net/data/auto

Bug#887060: testing migration happened despite FTBFS on arch:all buildd

Hi all, On Thu, 15 Nov 2018 20:49:43 +0100 Paul Gevers wrote: > I think I have found the cause for this issue. Apparently some arch:all > binary packages are not listed in both the binary-/Packages.* and > binary-all/Packages.* file groups, but ONLY in the binary-all/Packages.* > fil

Bug#976386: transition: octave

Hi Sébastien, On 20-12-2020 19:15, Sébastien Villemot wrote: > I’m not familiar with britney’s output, but my impression is that the > problem is related to src:plplot. The version in testing currently > builds a binary package named octave-plplot, which has been dropped in > the version currently

Re: Transition freeze clarification

Hi Vasyl, On 08-01-2021 22:22, Vasyl Gello wrote: > 1. If I intend to publish a new Kodi release to unstable during > 'Transition Freeze' but before 'Soft Freeze', and that release drops to > NEW queue due to binary package added, will it migrate to testing after > FTP Masters approve it? The chan

Re: unblocking zfs-linux/2.0.1-1 for migration

Hi, On 12-01-2021 15:41, cdlumin...@gmail.com wrote: > I'm confused by the migration status page for src:zfs-linux > https://qa.debian.org/excuses.php?package=zfs-linux Thanks for reaching out. > It says Rejected/violates migration policy/introduces a regression, > but the RC bugs were already f

Bug#976811: transition: php8.0

Hi Ondřej, On 12-01-2021 12:40, Ondřej Surý wrote: > I guess we are going to release with PHP 7.4 then.  Not the ideal > choice, but I will do whatever I can to support it. That's correct. > However, I would like to get an official statement from the release team > what's their position, so we c

Bug#980088: silxs autopkgtest

Package: release. User: release.debian@package.debian.org Severity: minor Usertag: britney Control: retitle -1 britney adds reference link for removed packages Hi Frederic-Emmanuel On 14-01-2021 09:26, PICCA Frederic-Emmanuel wrote: > I try to understand something about autopkgtest and britne

Bug#973342: libdbi-perl 1.642-1+deb10u2 flagged for acceptance

Hi all, On Sun, 20 Dec 2020 18:48:21 + Adam D Barratt wrote: > The upload referenced by this bug report has been flagged for acceptance into > the proposed-updates queue for Debian buster. The queue overview page [1] shows regressions in the autopkgtest of libdbd-csv-perl on all architectur

Bug#978750: openjdk-N (non-default) should not trigger autopkg tests

Control: retitle -1 britney: autopkgtest only tests first alternative Hi, On 31-12-2020 10:55, Matthias Klose wrote: > openjdk-N (non-default) should not trigger autopkg tests. Maybe, but default-jre, openjdk-11-jre, openjdk-13-jre, openjdk-14-jre, openjdk-15-jre, openjdk-16-jre, openjdk-8-jre

Bug#980520: britney: excuses: reduce verbosity of autopkgtest results

Hi Paul On 20-01-2021 06:26, Paul Wise wrote: > The excuses page is often very verbose because of the autopkgtest > results, especially for packages with lots of reverse dependencies. > > For packages where all the results are Pass, those packages could be > left out of the excuses altogether, si

Bug#980520: britney: excuses: reduce verbosity of autopkgtest results

Hi, On 21-01-2021 02:23, Paul Wise wrote: >> Passing packages that are still shown are those where an update >> happened since the successful run, so they are more or less >> "pending". I realize that probably nobody realizes this. > > It is very non-obvious from the output, I'd suggest putting P

Bug#980762: buster-pu: package cacti/1.2.2+ds1-2+deb10u4

in the current code where an attacker, once +having gained access to the Cacti database through a SQL injection, +could modify data in tables to possibly expose an stored XSS bug in + Cacti. + + -- Paul Gevers Thu, 21 Jan 2021 20:16:38 +0100 + cacti (1.2.2+ds1-2+deb10u3) bu

Bug#980835: buster-pu: fcitx/1:4.2.9.6-5+deb10u1

Hi Boyuan, On 22-01-2021 23:55, Boyuan Yang wrote: > Current fcitx v4.2.9.6 in Debian 10 has a broken implementation to > flatpak support. As a result, software installed via flatpak cannot > enable fcitx as the active input method. The corresponding Debian bug > report is at https://bugs.debian.o

Re: Issues in OpenStack packages right now

Hi Thomas, On 23-01-2021 01:26, Thomas Goirand wrote: > So I'm well aware that everything should have been working and been > tested at this point in time, though all I'm asking is a bit (in > advance) understanding for the late fix which are probably coming. > > Your thoughts are very much welco

Re: planning to upload binutils 2.35.2

Hi Matthias, On 26-01-2021 18:57, Matthias Klose wrote: > I would like to upload binutils version 2.5.2-1 to unstable later this week. > The > 2.25.2 release is announced for this weekend ([1]). It imports fixes towards > the next stable version. > > The pending fixes in the package are: > >

Re: planning to upload binutils 2.35.2

Hi Matthias, On 27-01-2021 22:42, Matthias Klose wrote: > I have been following the way the linux source package was uploaded. > Apparently > the package entered unstable with just an announcement like this. And more > than > one time. For linux there was alignment, but see below. >> So, can

Bug#981232: unblock: perl/5.32.1-1

Control: tags -1 moreinfo Hi Dominic, (Your bug title is wrong, as you can't use that version anymore as it's already in experimental ;) ) On 28-01-2021 00:39, Dominic Hargreaves wrote: > I should have probably > written all that in a bug instead so it can be tracked effectively. Indeed. > As

Bug#981232: unblock: perl/5.32.1-1

Hi Dominic, On 28-01-2021 22:05, Dominic Hargreaves wrote: >>> 5.32.1 would need a binnmu of a few leaf packages >>> (libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl >>> libcommon-sense-perl) as usual. >> >> Just to be clear, these binNMU's would be needed too if we would go for >>

Re: planning to upload binutils 2.35.2

Hi Matthias, On 29-01-2021 12:13, Matthias Klose wrote: >> We would be happy with either of the following: >> 1) upload to unstable with PR27218 only >> 2) upload to experimental first (with a 2.36+really2.35.2 version) to >> check all is fine. > > so I don't see what an upload for 2) would provi

Bug#981232: unblock: perl/5.32.1-1

Hi, On 28-01-2021 22:36, Dominic Hargreaves wrote: >> Would you have also asked us if you wouldn't have needed the binNMU's? > > Yes, since https://release.debian.org/bullseye/freeze_policy.html says > changes to build-essential may only be made with pre-approval... Right. Thank you, I should le

Re: from >3500 down to 11 (packages in bullseye not built on buildds)

Hi Holger, On 30-01-2021 18:41, Holger Levsen wrote: > bsdowl is marked for autoremoval on Februay 20th but the autoremoval > will not happen as that date is after the soft freeze, after which > autoremovals > will not ahappen anymore. https://release.debian.org/bullseye/free

Re: question regarding possible needed further action on package arduino

Hi Carsten, On 30-01-2021 08:18, Carsten Schoenert wrote: > after a month of concentrate work together with Rock Storm on the > arduino package , and some related build depending packages the Debian > Electronics Team is happy we have now an updated Arduino IDE package in > unstable. > > https://

Re: why was bitcoin package removed from testing?

Hi Jonas, On 30-01-2021 11:50, Jonas Smedegaard wrote: > If the release team consider bitcoin unacceptable for Debian stable, > then please elaborate why. We consider it unacceptable for Debian bullseye because the security team doesn't want to support it. Paul OpenPGP_signature Description:

Re: planning to upload binutils 2.35.2

Hi On 29-01-2021 12:13, Matthias Klose wrote: >> We would be happy with either of the following: >> 1) upload to unstable with PR27218 only >> 2) upload to experimental first (with a 2.36+really2.35.2 version) to >> check all is fine. > > so I don't see what an upload for 2) would provide you wit

Bug#981232: unblock: perl/5.32.1-1

Control: tag -1 confirmed Hi, On 31-01-2021 21:50, Niko Tyni wrote: > please consider approving 5.32.1. I think it would be > better to release bullseye with that than a Debian-specific 5.32.0 with > the patches from 5.32.1 (but both options are better than not having > the patches at all.) Plea

Bug#981232: unblock: perl/5.32.1-1

Hi, On 02-02-2021 08:47, Dominic Hargreaves wrote: > Please rebuild these packages as discussed: > > $ wb nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl > libcommon-sense-perl libdevel-mat-dumper-perl . ANY . -m "Rebuild against > perlapi-5.32.1." --extra-depends 'perl-base

Re: Don't ship gnupg1 with bullseye

Hi, On 02-02-2021 09:54, Dominic Hargreaves wrote: > The impression I got from the > release team and Chris Hofstaedtler that request-tracker4 was the only > thing blocking removal. The reason I (with my Release Team member hat on) was trying to figure out what needed to happen to enable removal

Re: Podman 3.0 and Debian bullseye

Hi Reinhard, On 25-01-2021 02:02, Reinhard Tartler wrote: > I'm not really sure if this update required formal approval by the > release team, but I'd really appreciate your input in any case. It doesn't, except that we wrote this in the freeze policy: """ No large/disruptive changes Any change

Re: Please allow pdns/4.4.1-1 into bullseye

Hi Chris, On 08-02-2021 09:32, Chris Hofstaedtler wrote: > I've uploaded that yesterday, and that was "just too late"? What makes you think so? Migration status for pdns (4.4.0-3 to 4.4.1-1): Waiting for test results, another package or too young (no action required now - check later) Is

Bug#982401: britney doesn't properly reschedule migration-reference/0 runs anymore

Package: release.debian.org X-Debbugs-CC: hert...@debian.org User: release.debian@packages.debian.org Usertags: britney Hi myself, I believe that since the patch to remember results for a particular trigger from older versions of the reverse dependency britney2 doesn't properly refreshes migr

<    4   5   6   7   8   9   10   11   12   13   >