Processed: update RM bug titles
Processing commands for cont...@bugs.debian.org: > retitle 915003 RM: mdk [armel] -- RoQA; guile-2.2 is not available on armel Bug #915003 [ftp.debian.org] RM: mdk [armel] guile-2.2 is not available on armel Changed Bug title to 'RM: mdk [armel] -- RoQA; guile-2.2 is not available on armel' from 'RM: mdk [armel] guile-2.2 is not available on armel'. > retitle 915002 RM: gnubik [armel] -- RoQA; guile-2.2 is not available on armel Bug #915002 [ftp.debian.org] RM: gnubik [armel] guile-2.2 is not available on armel Changed Bug title to 'RM: gnubik [armel] -- RoQA; guile-2.2 is not available on armel' from 'RM: gnubik [armel] guile-2.2 is not available on armel'. > retitle 915001 RM: dico [armel] -- RoQA; guile-2.2 is not available on armel Bug #915001 [release.debian.org] transition: xmltooling Changed Bug title to 'RM: dico [armel] -- RoQA; guile-2.2 is not available on armel' from 'transition: xmltooling'. > End of message, stopping processing here. Please contact me if you need assistance. -- 915001: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915001 915002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915002 915003: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915003 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: retitle 915052 to perl mini-transition for 5.28.1
Processing commands for cont...@bugs.debian.org: > retitle 915052 perl mini-transition for 5.28.1 Bug #915052 [release.debian.org] nmu: libpar-packer-perl_1 Changed Bug title to 'perl mini-transition for 5.28.1' from 'nmu: libpar-packer-perl_1'. > thanks Stopping processing here. Please contact me if you need assistance. -- 915052: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915052 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Is using experimental distribution for shelter during freeze useful?
Hi, On 27-11-18 12:38, Hideki Yamane wrote: > Well, we use experimental as "shelter" during freeze, but it's not good > in my point of view. > > - During freeze, it is just ignored by most of the users since they >wouldn't know there's a newer package in there (and they also afraid >because it's in "experimental" ;). It means "not tested" if they were >in Debian repository for a long time period > - Re-uploading to unstable is just boring, and no values are added by it > - unstable users wants new valued packages constantly. After release, >"package flood" to unstable is not good. > > So, I guess putting fixed packages into "testing-proposed-updates" and > to continue to upload packages to unstable during freeze period is better. > > Pros) > - unstable distribution stays newest > - No "unintended" changes will be introduced into testing during freeze > > Cons) > - Maybe you should do cherry-picking changes from unstable to >testing-proposed-updates, not just ask "unblock" to Release Managers. > - Harder to get users for test with testing-proposed-updates repository > > Your thoughts? I am not a member of the release team, but I am involved in recent changes to some of the tools used for migration from unstable to testing. Since the previous release, those tools and the QA they rely on have moved in the opposite direction of what you want and have made the request stronger to not upload disruptive changes to unstable during the freeze. Also see the release team's statement on this topic [1]: "It is usually better to revert the changes in unstable and upload the fix there.". If you want to make this an option for bullseye (I believe it is too late to properly implement and test this all now), I propose to help improve the QA and workflow via testing-proposed-updates, as I have the impression that the people currently involved in the QA and workflow (including me) are not interested to work towards your solution themselves. So to answer your question: yes, using experimental during the freeze for uploads not intended to be included in the next stable release is useful. Paul [1] https://release.debian.org/buster/freeze_policy.html (under "Changes which can be considered") signature.asc Description: OpenPGP digital signature
Bug#913069: python3-arcus + python3-savitar missing in the transition page, but uninstallable
On Wed, Nov 28, 2018 at 11:20:48PM +0100, Gregor Riepl wrote: > I can replace python3-all-dev with python3-dev for now, but it would be better > to actually fix this and have multi-python builds. > > Arcus and Savitar are SIP modules written in C++ and built with cmake. > It's not trivial to make them build automagically for all installed Python > versions. I acknoledge, cmake is not really suited to this kind of build, and it often requires quite some tinkering. OTOH, I don't see using python3-dev instead of python3-all-dev as a workaround, as it's there exactly for cases like this; so I'd appreciate if you could switch the build-depends in the next uploads, until you don't manage to find the time to work on building for multiple versions (if you ever do, it's not so strictly needed). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#914392: transition: coin3
On 28/11/2018 23:32, Leopold Palomo-Avellaneda wrote: > El 28/11/18 a les 19:12, Emilio Pozuelo Monfort ha escrit: >> On 22/11/2018 23:33, Leopold Palomo-Avellaneda wrote: >>> Subject: transition: coin3 >>> Package: release.debian.org >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> Severity: normal >>> >>> Dear release team, >>> >>> I would like to ask a transition slot for the coin3 library. The package >>> has been reworked and a new version of the upstream has been packaged. >>> >>> Upstream have changed the build system to CMake and this has been used >>> for the package. This has an implication that it will break with FTBFS >>> the packages that use it: pivy, freecad, openscenegraph-3.4 and soqt, I >>> have contacted with all the maintainers and they are aware about it and >>> we are preparing patches or simple disable in any case. >> >> Where are you discussing that? > > Almost all of them in private mails. I will adopt SoQt. I have been > working with that package and Anton Gladky know all my work. You can > check [1] qt5 branch. > > With Kurt Kremitzki (freecad and pivy) we are in contact about how to > solve the migration. > > And with openscenegraph I have interchanged some mail with one of the > maintainer about that. > > I don't see bug reports for those packages. >> Please file bugs so that we can track the status and decide when to start >> this >> transition based on the disruption that it will cause. Also please make those >> bugs block this one. > > we are waiting to have coin in unstable to push new versions/patches. About: > > - soqt, no problematic. I have done it > - pivy. I was not able to build it with the coin3 cmake version. Waiting > that Kurt work on it. I'm not an Python expert. But it should be reasonable. > - Freecad, depends on pivy. The new version doesn't depends on soqt. > - openscengraph, it only uses coin to import wrl files in a plugin. In > the worse case it can be disabled, but that > > Are you proposing that I fill a bug before the package fails? Yes. coin3 is already in experimental, but even if it wasn't you could still file the bug. So yes, file them with the latest status updates (patches, plan, etc) and make those bugs block this one. Cheers, Emilio
Bug#914516: transition: hunspell
Hi, On Wed, Nov 28, 2018 at 10:42:14PM +0100, Rene Engelhard wrote: > On Wed, Nov 28, 2018 at 07:07:54PM +0100, Emilio Pozuelo Monfort wrote: > > On 24/11/2018 11:07, Rene Engelhard wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > hunspell 1.7 was finally released. It includes a load of fixes > > > we miss e.g. in LibreOffice because instead of using the > > > patched-internal version we use the system version. > > > > > > Cleared NEW just now. > > > > > > So I'd like to get this transition done asap after > > > icu/boost/python3.7-as-default is done :) > > > > > > Did a rebuild using ratt and (almost) all packages built fine, except > > > some otherwise failing packages (mudlet and plume-creator (both sid > > > only) because of #907159 and #887534) > > > I skipped firefox, too; firefox-esr is fine. > > > (And libreoffice, but libreoffice is "of course" fine, too) > > > > Go ahead. > > Uploaded. Installed everywhere (except ksd where it is only Built but not uploaded for hours), so you can schedule bin-NMUs. Regards, Rene
Bug#914516: transition: hunspell
block 914516 by 915060 thanks Hi, On Thu, Nov 29, 2018 at 10:17:49PM +0100, Rene Engelhard wrote: > > Uploaded. > > Installed everywhere (except ksd where it is only Built but not uploaded > for hours), so you can schedule bin-NMUs. Noticed link-grammar (though it builds) fails the autopkgtest of the testing version because its test assumes stuff which isn't fullfilled. See #915060 for my analysis Regards, Rene
Processed: Re: Bug#914516: transition: hunspell
Processing commands for cont...@bugs.debian.org: > block 914516 by 915060 Bug #914516 [release.debian.org] transition: hunspell 914516 was not blocked by any bugs. 914516 was not blocking any bugs. Added blocking bug(s) of 914516: 915060 > thanks Stopping processing here. Please contact me if you need assistance. -- 914516: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914516 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed (with 5 errors): Re: Processed: update RM bug titles
Processing commands for cont...@bugs.debian.org: > # Not sure which bug you meant, but let's fix the > # obvious typo > retitle 915001 transition: xmltooling Bug #915001 [release.debian.org] RM: dico [armel] -- RoQA; guile-2.2 is not available on armel Changed Bug title to 'transition: xmltooling' from 'RM: dico [armel] -- RoQA; guile-2.2 is not available on armel'. > On Fri, 2018-11-30 at 02:03 +, Debian Bug Tracking System wrote: Unknown command or malformed arguments to command. > > retitle 915001 RM: dico [armel] -- RoQA; guile-2.2 is not available Unknown command or malformed arguments to command. > > > on armel Unknown command or malformed arguments to command. > > Unknown command or malformed arguments to command. > > Bug #915001 [release.debian.org] transition: xmltooling Unknown command or malformed arguments to command. Too many unknown commands, stopping here. Please contact me if you need assistance. -- 915001: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915001 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Processed: update RM bug titles
# Not sure which bug you meant, but let's fix the # obvious typo retitle 915001 transition: xmltooling On Fri, 2018-11-30 at 02:03 +, Debian Bug Tracking System wrote: > retitle 915001 RM: dico [armel] -- RoQA; guile-2.2 is not available > > on armel > > Bug #915001 [release.debian.org] transition: xmltooling > Changed Bug title to 'RM: dico [armel] -- RoQA; guile-2.2 is not > available on armel' from 'transition: xmltooling'.
Bug#915001: transition: xmltooling
Package: release.debian.org Severity: normal Tags: pending User: release.debian@packages.debian.org Usertags: transition Hi, please create a tracker and schedule binNMUs for the ongoing xmltooling transition. There is no automatic tracker, since the corresponding package stack has been removed from testing half a year ago. Andreas Ben file: title = "xmltooling"; is_affected = .depends ~ "libxmltooling7" | .depends ~ "libxmltooling8"; is_good = .depends ~ "libxmltooling8"; is_bad = .depends ~ "libxmltooling7";
Processed: forcibly merging 913614 914944
Processing commands for cont...@bugs.debian.org: > forcemerge 913614 914944 Bug #913614 [gnupg] gnupg2 fails with "cannot open '/dev/tty': No such device or address" Bug #913614 [gnupg] gnupg2 fails with "cannot open '/dev/tty': No such device or address" No longer marked as fixed in versions 2.2.2. Bug #914944 [gnupg] gnupg: importing a key fails when there's no tty (regression from 2.1.18-8~deb9u2) Severity set to 'serious' from 'normal' 914944 was not blocked by any bugs. 914944 was not blocking any bugs. Added blocking bug(s) of 914944: 914032 Marked as fixed in versions gnupg2/2.2.2-1. Added tag(s) confirmed, patch, and stretch. Merged 913614 914944 > thanks Stopping processing here. Please contact me if you need assistance. -- 913614: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913614 914944: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914944 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#915052: nmu: libpar-packer-perl_1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu As is usual for a patch release of perl, we need to binnmu a small number of packages: nmu libpar-packer-perl libdevel-cover-perl libclass-xsaccessor-perl libcommon-sense-perl . ANY . -m "Rebuild against perlapi-5.28.1." --extra-depends 'perl-base (>= 5.28.1)' Thanks! Dominic. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
