Bug#998057: transition: r-api-bioc-3.14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debia...@lists.debian.org Hi, Bioconductor 3.14 was released [1]. [1] https://bioconductor.org/news/bioc_3_14_release/ Like for previous r-api-bioc transitions, all reverse dependencies need a manual upgrade to the new upstream releases, they are not binNMU-able. The Debian R Packages team will do so. Please set up a tracker manually, since this is a transition of a virtual package name. Ben file: - title = "r-api-bioc-3.14"; is_affected = .depends ~ /r-api-bioc/; is_good = .depends ~ "r-api-bioc-3.14"; is_bad = .depends ~ "r-api-bioc-3.13"; - Best, Dylan
Bug#998067: transition: libsepol and libsemanage
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, libsepol and libsemanage have both bumped their soname from 1 to 2, the packages already went through the NEW queue and are in experimental. The transition trackers are already created: https://release.debian.org/transitions/html/auto-libsepol.html https://release.debian.org/transitions/html/auto-libsemanage.html Most of the packages are from the same upstream. For libsemanage, sssd and shadow will have to adjust their build-dependencies For libsepol, dmraid must remove the build-dependency, this is useless, see #929484. Note that dmraid already has a RC bug, for other reasons. Kind regards, Laurent Bigonville
Bug#995587: transition: ruby3.0-add
On Thu, Oct 28, 2021 at 11:34:28PM +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > On 2021-10-20 09:45:10 -0300, Antonio Terceiro wrote: > > Control: tag -1 - moreinfo > > > > On Sat, Oct 16, 2021 at 03:46:11PM +0200, Sebastian Ramacher wrote: > > > Control: tags -1 moreinfo > > > > > > On 2021-10-15 06:44:36 -0300, Antonio Terceiro wrote: > > > > Hi, > > > > > > > > On Sat, Oct 02, 2021 at 03:14:39PM -0300, Antonio Terceiro wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > > > > > > We would like to add support for ruby3.0 in ruby-defaults. > > > > > > > > > > Ben file: > > > > > > > > > > title = "ruby3.0-add"; > > > > > is_affected = (.depends ~ /ruby2.7 | .depends ~ /ruby3.0/) & !.source > > > > > ~ /^(ruby2.7|ruby3.0|ruby-defaults)$/); > > > > > is_good = .depends ~ /ruby3.0/; > > > > > is_bad = .depends ~ /ruby2.7/ & !.depends ~ /ruby3.0/; > > > > > > > > > > We already did a mass rebuild some time ago, and the results don't > > > > > look > > > > > bad. We should be doing a new one soon, and will come up with a list > > > > > of > > > > > binNMUs > > > > > > > > This is a friendly ping. We would like to make the switch in unstable > > > > soon and start doing binNMUs. > > > > > > > > We have these bugs related to this transition: > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ruby3.0;users=debian-r...@lists.debian.org > > > > > > > > Most of those bugs are for leaf libraries. We already started fixing the > > > > ones that block a lof of other (e.g. the ones with C extensions that > > > > FTBFS with ruby3.0) so they are ready to be binNMUed. > > > > > > ruby3.0 isn't in testing yet - it currently fails to build on ppc64el. > > > So let's at least wait until it migrated. > > > > ruby3.0 is now in testing. Can we go ahead with this? > > Yes, please go ahead Thanks, we will upload ruby-defaults shortly. Note that we do not necessarily want/need to block involved packages from migrating, as adding ruby3.0 support does not break anything since the default is still unchanged. signature.asc Description: PGP signature
Bug#995587: transition: ruby3.0-add
On Thu, 28 Oct 2021 23:34:28 +0200 Sebastian Ramacher wrote: > Yes, please go ahead I just uploaded ruby-defaults/1:2.7.6 to unstable adding ruby3.0 as an alternative interpreter, it should be available soon. Below you can find a list of binNMUs for the dependency level 1: dislocker epic5 graphviz hivex kamailio klayout kross-interpreters libprelude libselinux marisa mecab ngraph-gtk notmuch protobuf qdbm raspell redland-bindings remctl rrdtool ruby-atomic ruby-augeas ruby-bcrypt ruby-bcrypt-pbkdf ruby-bert ruby-bindex ruby-binding-ninja ruby-cairo ruby-cbor ruby-character-set ruby-charlock-holmes ruby-concurrent ruby-cool.io ruby-curb ruby-curses ruby-damerau-levenshtein ruby-dataobjects-postgres ruby-dataobjects-sqlite3 ruby-debian ruby-debug-inspector ruby-eb ruby-ed25519 ruby-enumerable-statistics ruby-escape-utils ruby-eventmachine ruby-exif ruby-fast-blank ruby-fast-stemmer ruby-fast-xs ruby-fcgi ruby-ffi ruby-ffi-yajl ruby-filesystem ruby-fusefs ruby-gitlab-pg-query ruby-god ruby-gpgme ruby-hiredis ruby-hitimes ruby-jaro-winkler ruby-kgio ruby-ldap ruby-levenshtein ruby-libxml ruby-liquid-c ruby-murmurhash3 ruby-mysql2 ruby-narray ruby-ncurses ruby-nfc ruby-nio4r ruby-nokogiri ruby-odbc ruby-oily-png ruby-oj ruby-ox ruby-pcaprub ruby-pg ruby-posix-spawn ruby-prof ruby-prometheus-client-mmap ruby-rblineprof ruby-rbtree ruby-rdiscount ruby-re2 ruby-redcarpet ruby-redcloth ruby-regexp-property-values ruby-rinku ruby-rjb ruby-rmagick ruby-rpam-ruby19 ruby-rpatricia ruby-rugged ruby-sdl ruby-sequel-pg ruby-serialport ruby-shadow ruby-stackprof ruby-strptime ruby-termios ruby-thrift ruby-timfel-krb5-auth ruby-tioga ruby-tokyocabinet ruby-uconv ruby-unf-ext ruby-unicode ruby-version-sorter ruby-vmstat ruby-websocket-driver ruby-xmlhash ruby-xmlparser ruby-yajl ruby-zoom spglib stfl subtle subversion uwsgi vim-command-t weechat xapian-bindings The following packages are also part of the dependency level 1 but they are still FTBFSes, let's skip them for now. obexftp ruby-byebug ruby-ferret ruby-dataobjects-mysql ruby-gd ruby-json ruby-kyotocabinet ruby-libvirt ruby-mmap2 ruby-psych ruby-ruby-magic-static ruby-sigar -- Lucas Kanashiro
Bug#995055: marked as done (transition: glew)
Your message dated Fri, 29 Oct 2021 22:35:49 +0200 with message-id and subject line Re: Bug#995055: transition: glew has caused the Debian Bug report #995055, regarding transition: glew 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.) -- 995055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995055 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 X-Debbugs-Cc: debian-de...@lists.debian.org This transition is triggered by an SONAME change upstream. It does not appear to have any API transition though, and seems to cause no glew-related failures. Ben file: title = "glew"; is_affected = .depends ~ "libglew2.1" | .depends ~ "libglew2.2"; is_good = .depends ~ "libglew2.2"; is_bad = .depends ~ "libglew2.1"; I've rebuilt all dependencies, with a number of unrelated FTBFS: Bugs have been submitted against all FTBFS. glew OK info-beamer : : change bd libglew1.5-dev -> libglew-dev OK phlipple: change bd libglew1.5-dev -> libglew-dev OK pymol: change bd libglew1.5-dev -> libglew-dev OK rlvm: change bd libglew1.5-dev -> libglew-dev OK asymptote: OK avogarolibs: OK ball: FTBFS (#994480) unrelated (glibc/ rpc header change) bino: OK blastem: OK blender: OK bzflag: OK casparcg-server (sid only): FTBFS (#947518) colmap: OK colobot: OK compiz-plugins-experimental: OK darkradiant: OK ddnet: OK dreamchess: OK endless-sky: OK fife: OK freeorion: OK frogatto (contrib): OK gambas3: OK gource: OK hugin: OK hyperrogue: OK k3d (sid only): FTBFS (python2 issues) kicad: OK limesuite: OK logstalgia: OK mediastreamer2: (FTFBS with gcc-11), OK megaglest : OK mesa-demos: OK mupen64plus-video-z64: OK mygui: OK open3d: OK openclonk: opencsg: OK openctm: OK openmsx:: OK otb: OK paraview: OK qutemol: OK rbdoom3bfg: OK renpy (sid only):FTBFS - needs python-sphinx rss-glx: OK scorched3d: OK slic3r-prusa OK slop: FTBFS (#994824) unrelated sludge: OK sofa-framework: FTBFS (#875184): QT4 removed spring: OK supertux: OK supertuxkart: OK trigger-rally: OK tulip: OK vice (contrib): FTBFS #994835 (jpeg support missing) vtk7: OK vtk9: OK warzone2100: OK widelands: OK cegui-mk2: OK meshlab; OK openscad: FTBFS (#994937) CGAL-related ? pcl:OK --- End Message --- --- Begin Message --- On 2021-09-29 16:23:51 +0200, Sebastian Ramacher wrote: > On 2021-09-29 10:01:18 +0200, Sebastian Ramacher wrote: > > Control: tags -1 confirmed > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-glew.html > > > > On 2021-09-25 12:24:06 +0100, Alastair McKinstry wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > > > This transition is triggered by an SONAME change upstream. > > > It does not appear to have any API transition though, and seems to cause > > > no glew-related failures. > > > > > > Ben file: > > > > > > title = "glew"; > > > is_affected = .depends ~ "libglew2.1" | .depends ~ "libglew2.2"; > > > is_good = .depends ~ "libglew2.2"; > > > is_bad = .depends ~ "libglew2.1"; > > > > > > I've rebuilt all dependencies, with a number of unrelated FTBFS: > > > Bugs have been submitted against all FTBFS. > > > > > > glew OK > > > info-beamer : : change bd libglew1.5-dev -> libglew-dev OK > > > phlipple: change bd libglew1.5-dev -> libglew-dev OK > > > pymol: change bd libglew1.5-dev -> libglew-dev OK > > > rlvm: change bd libglew1.5-dev -> libglew-dev OK > > Oh, and could you please file RC bugs for those? > > Cheers > > > > > > > asymptote: OK > > > avogarolibs: OK > > > ball: FTBFS (#994480) unrelated (glibc/ rpc header change) > > > bino: OK > > > blastem: OK > > > blender: OK > > > bzflag: OK > > > casparcg-server (sid only): FTBFS (#947518) > > > colmap: OK > > > colobot: OK > > > compiz-plugins-experimental: OK > > > darkradiant: OK > > > ddnet: OK > > > dreamchess: OK > > > endless-sky: OK > > > fife: OK > > > freeorion: OK > > > frogatto (contrib): OK > > > gambas3: OK > > > gource: OK > > > hugin: OK > > > hyperrogue: OK > > > k3d (sid only): FTBFS (python2 issues) > > > kicad: OK > > > limesuite: OK > > > logstalgia: OK > > > mediastreamer2: (FTFBS with gcc-11), OK > > > megaglest : OK > > > mesa-demos: OK > > > mupen64plus-video-z64: OK > > > mygui: OK > > > open3d: OK > > > openclonk: > > > opencsg: OK > > > openctm: OK > > > openmsx:: OK > > > otb: OK > > > paraview: OK > > > qutemol: OK > > > rbdoom3bfg: OK > > > renp
Bug#996204: transition: numerical library stack
On 2021-10-22 14:35, Sebastian Ramacher wrote: On 2021-10-12 13:09:02, Drew Parsons wrote: ... I'd like to proceed with a transition of the numerical library stack. ... (along with other fenics components). There is currently some problem with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf. I've got dolfinx passing (or skipping) its own tests on 32-bit. There's a problem with 32-bit MPI though. i386 and armhf are failing to run pytest over python unit tests in MPI (fenics-dolfinx/debian/tests/test-dolfinx-python-unittests). The error is reproducible from the command line on an i386 porterbox, $ cd fenics-dolfinx-0.3.0/python/test/unit $ mpirun -n 2 pytest-3 -v ... rootdir: /home/dparsons/fenics/fenics-dolfinx-0.3.0/python, configfile: setup.cfg plugins: mpi-0+unknown collecting 0 items / 1 error -- "MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 59." I haven't been able to coax any more detail out of it than that. Might be something more insidious going on with 32-bit python and MPI. mpi4py is also failing i386 tests, see https://ci.debian.net/packages/m/mpi4py/testing/i386/ https://github.com/mpi4py/mpi4py/issues/105 On the other hand fenics-dolfinx demo_elasticity.py is passing fine in MPI (though I did have to disable the helmholtz, condensation and poisson demos). pytest-mpi is passing its tests on i386 and armhf. What's best for us? Just skip the fenics-dolfinx python units tests in MPI on 32-bit machines? Or configure the migration tool to ignore these i386/armhf test failures, so that we can keep monitoring the tests in debci? Drew
