Bug#1055690: libgpuarray ftbfs with Python 3.12
Package: src:libgpuarray Version: 0.7.6-14 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 libgpuarray ftbfs with Python 3.12: [...] dh_auto_clean I: pybuild base:310: python3.12 setup.py clean /<>/versioneer.py:421: SyntaxWarning: invalid escape sequence '\s' LONG_VERSION_PY['git'] = ''' Traceback (most recent call last): File "/<>/setup.py", line 145, in version_data = versioneer.get_versions() ^ File "/<>/versioneer.py", line 1412, in get_versions cfg = get_config_from_root(root) ^^ File "/<>/versioneer.py", line 342, in get_config_from_root parser = configparser.SafeConfigParser() ^ AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'? E: pybuild pybuild:395: clean: plugin distutils failed with: exit code=1: python3.12 setup.py clean
Bug#1055689: RFS: python-jsbeautifier/1.14.11-1 -- JavaScript unobfuscator and beautifier
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-jsbeautifier": * Package name : python-jsbeautifier Version : 1.14.11-1 Upstream contact : Liam Newman, Einar Lielmanis, et al. * URL : https://github.com/beautify-web/js-beautify * License : MIT * Vcs : https://salsa.debian.org/debian/python-jsbeautifier Section : python The source builds the following binary packages: python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3) jsbeautifier - JavaScript unobfuscator and beautifier To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-jsbeautifier/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.14.11-1.dsc Changes since the last upload: python-jsbeautifier (1.14.11-1) unstable; urgency=medium . * New upstream release. * Rebase patches, drop 0002-Fix-brace-style-test.patch, included upstream. * Remove creation and deleting of __init__.py file in d/rules Regards, -- Håvard
Bug#1040378: qemu.desktop: invalid desktop file
10.11.2023 01:42, Thorsten Glaser : Package: qemu-system-data Version: 1:8.1.2+ds-1 Followup-For: Bug #1040378 X-Debbugs-Cc: t...@mirbsd.de But what *is* its purpose then? The application icon. Without this .desktop file, there will be no icon displayed for running qemus. /mjt
Bug#1055687: khmer ftbfs with Python 3.12
Package: src:khmer
Version: 3.0.0~a3+dfsg-5
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12
khmer ftbfs with Python 3.12
[...]
dh_auto_configure -O--buildsystem=pybuild
pybuild --configure -i python{version} -p "3.12 3.11"
I: pybuild base:310: python3.12 setup.py config
/<>/versioneer.py:421: SyntaxWarning: invalid escape
sequence '\s'
LONG_VERSION_PY['git'] = '''
*** NOTE: Found Cython, extension files will be transpiled if this is an
install invocation.
Traceback (most recent call last):
File "/<>/setup.py", line 200, in
"define_macros": [("VERSION", versioneer.get_version()), ],
File "/<>/versioneer.py", line 1480, in get_version
return get_versions()["version"]
^^
File "/<>/versioneer.py", line 1412, in get_versions
cfg = get_config_from_root(root)
^^
File "/<>/versioneer.py", line 342, in get_config_from_root
parser = configparser.SafeConfigParser()
^
AttributeError: module 'configparser' has no attribute
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
E: pybuild pybuild:395: configure: plugin distutils failed with: exit
code=1: python3.12 setup.py config
dh_auto_configure: error: pybuild --configure -i python{version} -p
"3.12 3.11" returned exit code 13
make: *** [debian/rules:16: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
Bug#1055688: libgetdata ftbfs with Python 3.12 as supported Python version
Package: src:libgetdata Version: 0.11.0-7 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 libgetdata ftbfs with Python 3.12 as supported Python version, hard-coding specific versions in the install file. $ cat debian/python3-pygetdata.install # usr/lib/python3*/site-packages/pygetdata*so usr/local/lib/python3.11/dist-packages/* /usr/lib/python3.11/site-packages please work around that in other ways, not having a concrete version hard-coded.
Bug#1055686: dm-tree ftbfs with Python 3.12
Package: src:dm-tree
Version:
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12
dm-tree ftbfs with Python 3.12, although the build and test of the
extension succeed with 3.12. The build then fails building the docs:
debian/rules execute_before_dh_sphinxdoc
make[1]: Entering directory '/<>'
cd $(pybuild --print build_dir --name dm-tree |head -n1 |awk -F ': '
'{print $2}'); python3 -m sphinx -b html -N /<>/docs
/<>/debian/python-dm-tree-doc/usr/share/doc/python-dm-tree-doc/html
Running Sphinx v7.2.6
Configuration error:
There is a programmable error in your configuration file:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/config.py", line 358, in
eval_config_file
exec(code, namespace) # NoQA: S102
^
File "/<>/docs/conf.py", line 34, in
import tree
File
"/<>/.pybuild/cpython3_3.12_dm-tree/build/tree/__init__.py",
line 23, in
from .sequence import _is_attrs
File
"/<>/.pybuild/cpython3_3.12_dm-tree/build/tree/sequence.py",
line 19, in
from tree import _tree
ImportError: cannot import name '_tree' from partially initialized
module 'tree' (most likely due to a circular import)
(/<>/.pybuild/cpython3_3.12_dm-tree/build/tree/__init__.py)
make[1]: *** [debian/rules:11: execute_before_dh_sphinxdoc] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
complete build log at
https://launchpadlibrarian.net/696984001/buildlog_ubuntu-noble-amd64.dm-tree_0.1.8-2_BUILDING.txt.gz
Bug#1055682: gdal b-d's on python3-all-dev, but only builds for the default python version
Control: tags -1 moreinfo On 11/10/23 07:55, Matthias Klose wrote: gdal b-d's on python3-all-dev, but only builds for the default python version. No it doesn't. The build is execute for all versions returned by py3versions -sv: https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L18 https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L46 https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L51-L53 https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L99 https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L104 https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L109 What makes you think that only the default is used? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055574: nose is not ready for Python 3.12
Hi Matthias! On Fri, Nov 10, 2023 at 07:43:06AM +0100, Matthias Klose wrote: > Control: tags -1 + patch > > * Take the Fedora patch, but don't apply it (introduces a test regression). > * (Build-)depend on python3-zombie-imp. > * Fix more Python 3.12 deprecations. > > http://launchpadlibrarian.net/696912675/nose_1.3.7-11_1.3.7-11ubuntu1.diff.gz Nose is team-maintained, so please go ahead and upload this. Although, I won't add the Fedora patch if you solved the problem by using zombie-imp. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055685: compreffor ftbfs with Python 3.12
Package: src:compreffor Version: 0.5.3-2 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 [...] Development mode: Compiling Cython modules from .pyx sources. running build running build_py creating /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor copying src/python/compreffor/pyCompressor.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor copying src/python/compreffor/__init__.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor copying src/python/compreffor/cxxCompressor.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor copying src/python/compreffor/_version.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor copying src/python/compreffor/__main__.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor creating /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor/test copying src/python/compreffor/test/util.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor/test copying src/python/compreffor/test/dummy.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor/test copying src/python/compreffor/test/pyCompressor_test.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor/test copying src/python/compreffor/test/__init__.py -> /<>/.pybuild/cpython3_3.11_compreffor/build/compreffor/test running build_ext building 'compreffor._compreffor' extension error: unknown file type '.pyx' (from 'src/cython/_compreffor.pyx') E: pybuild pybuild:395: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build
Bug#1055684: beancount fails tests with Python 3.12
Package: src:beancount Version: 2.3.5-3 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 === short test summary info FAILED beancount/ops/summarize_test.py::TestOpenClose::test_open - UnboundLoc... FAILED beancount/ops/summarize_test.py::TestOpenClose::test_open_close_clear FAILED beancount/ops/summarize_test.py::TestOpenCloseWithOptions::test_open FAILED beancount/ops/summarize_test.py::TestOpenCloseWithOptions::test_open_close_clear FAILED beancount/ops/summarize_test.py::TestClamp::test_clamp - UnboundLocalE... FAILED beancount/ops/summarize_test.py::TestTransferBalances::test_transfer_balances__end_assets_implicit FAILED beancount/ops/summarize_test.py::TestTransferBalances::test_transfer_balances__middle_assets FAILED beancount/ops/summarize_test.py::TestTransferBalances::test_transfer_balances__middle_at_cost FAILED beancount/ops/summarize_test.py::TestTransferBalances::test_transfer_balances__middle_income FAILED beancount/query/query_execute_test.py::TestFilterEntries::test_filter_open_dated FAILED beancount/query/shell_test.py::TestUseCases::test_balance_sheet - Asse... FAILED beancount/query/shell_test.py::TestUseCases::test_conversions - Assert... FAILED beancount/query/shell_test.py::TestUseCases::test_income_statement - A... FAILED beancount/query/shell_test.py::TestUseCases::test_journal - AssertionE... FAILED beancount/scripts/bake_test.py::TestScriptBake::test_bake_directory - ... FAILED beancount/scripts/bake_test.py::TestScriptArchive::test_bake_archive__known FAILED beancount/scripts/bake_test.py::TestScriptArchive::test_bake_directory FAILED beancount/web/views_test.py::TestViews::test_YearView - UnboundLocalEr... FAILED beancount/web/web_test.py::TestWeb::test_scrape_basic - urllib.error.H... FAILED beancount/web/web_test.py::TestWeb::test_scrape_basic_view - urllib.er... FAILED beancount/web/web_test.py::TestWeb::test_scrape_empty_file - urllib.er... FAILED beancount/web/web_test.py::TestWeb::test_scrape_in_incognito - urllib FAILED beancount/web/web_test.py::TestWeb::test_scrape_starterkit - urllib.er... 23 failed, 1682 passed, 22 skipped, 2 xfailed, 2487 warnings in 35.79s E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: cd /<>/.pybuild/cpython3_3.12/build; python3.12 -m pytest -v complete build log at https://launchpadlibrarian.net/696984020/buildlog_ubuntu-noble-amd64.beancount_2.3.5-3build1_BUILDING.txt.gz
Bug#1055683: gtsam b-d's on python3-all-dev, but only builds for the default python version
Package: src:gtsam Version: 4.2~9+dfsg-6 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 gtsam b-d's on python3-all-dev, but only builds for the default python version. Please build for all supported Python3 versions, or avoid the b-d's on the -all packages.
Bug#1055682: gdal b-d's on python3-all-dev, but only builds for the default python version
Package: src:gdal Version: 3.7.3+dfsg-1 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 gdal b-d's on python3-all-dev, but only builds for the default python version. Please build for all supported Python3 versions, or avoid the b-d's on the -all packages.
Bug#1055574: nose is not ready for Python 3.12
Control: tags -1 + patch * Take the Fedora patch, but don't apply it (introduces a test regression). * (Build-)depend on python3-zombie-imp. * Fix more Python 3.12 deprecations. http://launchpadlibrarian.net/696912675/nose_1.3.7-11_1.3.7-11ubuntu1.diff.gz
Bug#1055681: new upstream python is needed for Python 3.12
Package: src:cython Version: 0.29.36-1 Severity: important Tags: sid trixie User: debian-pyt...@lists.debian.org Usertags: python3.12 new upstream python is needed for Python 3.12. needs two extra b-d's for sphinx extensions. example packaging at https://launchpad.net/ubuntu/+source/cython/3.0.5-0ubuntu1
Bug#1055510: Best way to coordinate this fix
On 2023-11-08 at 21:15:58, Helmut Grohne (hel...@subdivi.de) wrote: > Thank you. I suggest going via experimental first. I've just uploaded to experimental. If there are any tests you can easily run there, please do so. I've upgraded in unstable from the current version to 0.8 without problems, so that should in theory work when I eventually upload to unstable. Francois -- https://fmarier.org/
Bug#1006911: thunar: Cannot use IPv6 addresses in remote URLs
Control: tags -1 fixed-upstream On Thu Aug 18 2022 11:11:25 GMT-0700 (Pacific Daylight Time), Philip Chung wrote:> Control: forwarded -1 https://gitlab.xfce.org/xfce/thunar/-/issues/864 > [...] I have reported this issue upstream because I am fairly confident that this is not distribution-specific. This has been fixed upstream in version 4.18.8 and 4.19.0. Philip Chung
Bug#1055680: libpython3.12-stdlib has an undeclared file conflict
Package: libpython3.12-stdlib Version: 3.12.0-3 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libpython3.12-testsuite libpython3.12-stdlib has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/python3.12/test/typinganndata/__init__.py * /usr/lib/python3.12/test/typinganndata/ann_module9.py are contained in the packages * libpython3.12-stdlib/3.12.0-3 as present in unstable * libpython3.12-testsuite/3.12.0-1 as present in trixie These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1055679: nvchecker and python3-nvchecker have an undeclared file conflict on 56 files
Package: nvchecker,python3-nvchecker Severity: serious User: debian...@lists.debian.org Usertags: fileconflict The files * /usr/bin/nvchecker * /usr/bin/nvchecker-ini2toml * /usr/bin/nvchecker-notify * /usr/bin/nvcmp * /usr/bin/nvtake * /usr/lib/python3/dist-packages/nvchecker/__init__.py * /usr/lib/python3/dist-packages/nvchecker/__main__.py * /usr/lib/python3/dist-packages/nvchecker/api.py * /usr/lib/python3/dist-packages/nvchecker/core.py * /usr/lib/python3/dist-packages/nvchecker/ctxvars.py * /usr/lib/python3/dist-packages/nvchecker/httpclient/__init__.py * /usr/lib/python3/dist-packages/nvchecker/httpclient/aiohttp_httpclient.py * /usr/lib/python3/dist-packages/nvchecker/httpclient/base.py * /usr/lib/python3/dist-packages/nvchecker/httpclient/httpx_httpclient.py * /usr/lib/python3/dist-packages/nvchecker/httpclient/tornado_httpclient.py * /usr/lib/python3/dist-packages/nvchecker/lib/__init__.py * /usr/lib/python3/dist-packages/nvchecker/lib/nicelogger.py * /usr/lib/python3/dist-packages/nvchecker/lib/packaging_version.py * /usr/lib/python3/dist-packages/nvchecker/slogconf.py * /usr/lib/python3/dist-packages/nvchecker/sortversion.py * /usr/lib/python3/dist-packages/nvchecker/tools.py * /usr/lib/python3/dist-packages/nvchecker/util.py * /usr/lib/python3/dist-packages/nvchecker_source/alpm.py * /usr/lib/python3/dist-packages/nvchecker_source/android_sdk.py * /usr/lib/python3/dist-packages/nvchecker_source/anitya.py * /usr/lib/python3/dist-packages/nvchecker_source/apt.py * /usr/lib/python3/dist-packages/nvchecker_source/archpkg.py * /usr/lib/python3/dist-packages/nvchecker_source/aur.py * /usr/lib/python3/dist-packages/nvchecker_source/bitbucket.py * /usr/lib/python3/dist-packages/nvchecker_source/cmd.py * /usr/lib/python3/dist-packages/nvchecker_source/combiner.py * /usr/lib/python3/dist-packages/nvchecker_source/container.py * /usr/lib/python3/dist-packages/nvchecker_source/cpan.py * /usr/lib/python3/dist-packages/nvchecker_source/cratesio.py * /usr/lib/python3/dist-packages/nvchecker_source/debianpkg.py * /usr/lib/python3/dist-packages/nvchecker_source/gems.py * /usr/lib/python3/dist-packages/nvchecker_source/git.py * /usr/lib/python3/dist-packages/nvchecker_source/gitea.py * /usr/lib/python3/dist-packages/nvchecker_source/github.py * /usr/lib/python3/dist-packages/nvchecker_source/gitlab.py * /usr/lib/python3/dist-packages/nvchecker_source/hackage.py * /usr/lib/python3/dist-packages/nvchecker_source/htmlparser.py * /usr/lib/python3/dist-packages/nvchecker_source/httpheader.py * /usr/lib/python3/dist-packages/nvchecker_source/manual.py * /usr/lib/python3/dist-packages/nvchecker_source/none.py * /usr/lib/python3/dist-packages/nvchecker_source/npm.py * /usr/lib/python3/dist-packages/nvchecker_source/openvsx.py * /usr/lib/python3/dist-packages/nvchecker_source/packagist.py * /usr/lib/python3/dist-packages/nvchecker_source/pacman.py * /usr/lib/python3/dist-packages/nvchecker_source/pagure.py * /usr/lib/python3/dist-packages/nvchecker_source/pypi.py * /usr/lib/python3/dist-packages/nvchecker_source/regex.py * /usr/lib/python3/dist-packages/nvchecker_source/repology.py * /usr/lib/python3/dist-packages/nvchecker_source/sparkle.py * /usr/lib/python3/dist-packages/nvchecker_source/ubuntupkg.py * /usr/lib/python3/dist-packages/nvchecker_source/vsmarketplace.py are contained in the packages * nvchecker/2.5-1 * python3-nvchecker/2.12-1 These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Please figure out which of these packages should properly own the affected files and reassign the bug as appropriate. When doing so, please add the other package to the set of affected packages using "Control: affects -1 + " to avoid the filing of duplicates. The other package should stop installing the files. In case the files are being moved between packages, Breaks and Replaces should be declared. In this case, please refer to policy section 7.6 for details. Another useful resource is https://wiki.debian.org/PackageTransition. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1055678: librnd4-lib-gtk has an undeclared file conflict
Package: librnd4-lib-gtk Version: 4.1.0-2 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + librnd4-hid-gtk4-gl librnd4-lib-gtk has an undeclared file conflict. This may result in an unpack error from dpkg. The files * /usr/lib/librnd4/plugins/lib_gtk4_common.pup * /usr/lib/librnd4/plugins/lib_gtk4_common.so are contained in the packages * librnd4-hid-gtk4-gl/4.0.3-1 as present in trixie * librnd4-lib-gtk/4.1.0-2 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Attempting to unpack these packages concurrently results in an unpack error from dpkg, because none of the packages installs a diversion for the affected files. Kind regards The Debian Usr Merge Analysis Tool This bug report has been automatically filed with no human intervention. The source code is available at https://salsa.debian.org/helmutg/dumat. If the filing is unclear or in error, don't hesitate to contact hel...@subdivi.de for assistance.
Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal
Hi Nilesh, Here's what I thought of the discussion. On Thu, 2023-11-09 at 22:53 +0530, Nilesh Patra wrote: > > It would probably be beneficial if we could setup the gbp workflow by hand, > > ensuring the upstream branch is up to date > > Not sure what you mean here. `gbp import-orig` takes care of it. My mistake, I thought that the gbp workflow can only be setup with a new git repo and a dsc. Having a look at the gbp docs has cleared this up for me. > > and setting up a patch-queue/debian/(unstable|experimental) branch. > > No, please. These are never really meant to be pushed. Besides people use > different > way to apply patches - I use quilt and not `gbp pq`. Thanks for clarifying that matter, it was a bit unclear to me. (I had pushed the patch-queue branch to [2] and [3] thinking that was the way to go.) > > Regarding commit 7020dd5d: > > Are the ldflags necessary, since the binary builds fine without them set? > > Especially the kitty.VCSRevision option, which is only really used in > > --version, > > as shown in this upstream commit[9]. > > I do not find any commit at [9] but rather the lintian output. I simply > decided to emulate the way in which upstream buildsystem would behave to > avoid surprises so I'd be OK with keeping it that way. LMK if you > disagree. Sorry, wrong link. I meant [10]. But I don't think this applies anymore, as the tools/cli/infrastructure.go file has been removed. I cloned the upstream repo, built it using setup.py, and passed the build option `--vcs-rev=VCS_REV_GOES_HERE`. After running `strings ./kitty/launchers/kitty | grep -i VCS_REV_GOES_HERE`, and the same with the kitten binary, no mention of the VCS revision was found, except for the following in "kitten": build -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE" build -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE" So I don't think it matters whether we pass the VCSRevision in ldlags or not, nor what value we pass, since it's not being used. I agree with passing the other ldflags though, in order to emulate setup.py and the upstream buildsystem. Forgive me for overemphasizing this, but I wanted to get to the bottom of this. > > > > Should we add a simple recursive find and replace to debian/rules [to change > > the shebangs from python to python3]? WDYT? > > The problem with such a call is that the package can't build again > after the first build due to non-patch changes in the files. So if we > are doing a recursive replace, it should be done in the > "override_dh_python3" step on the files *inside* debian dir. > > OTOH, it may be possible to do so "dh_python3 > --shebang=/usr/bin/python3" magic to get this fixed. > > To be clear, recursive find and replace is OK for me as long as it is > done in a later step inside the files in debian/ dir. Feel free to go > ahead with a fix. Done. I've added a recursive find and replace to override_dh_auto_install in debian/rules, which goes through the debian/tmp/usr/lib/kitty directory that is copied beforehand. > That said I do see a directive to "/usr/bin/env python3" in specific > files for instance in "kittens/tui/handler.py" "kitty/fonts/render.py" > but not in others. IMHO we should ask upstream to maintain uniformity by > fixing this. I agree. Should we open an issue and/or PR upstream? > > > * Since we both are interested in kitty's packaging, I think we have two > > > options: > > > - Either you or me would be in the "Maintainer" field and the other one > > > would > > > be in "Uploader" field. > > > - Add ki...@packages.debian.org as the maintainer and add both of us > > > as uploaders (that means we subscribe to the package email > > > ofcourse). > > > Which one do you think we should do? > > > > I don't really have a preference, so I'm happy with whatever you would like > > to > > do regarding that. > > So I suppose the question now changes to: "Would you like to be > responsible to maintain this package and commit to its maintenance as a > primary PoC"? > > > Keep in mind that the contact in the Maintainer field will > > pretty much be the "face" of the package. > > I've maintained a fair bit of python and go packages for a few years > even before I was a Debian Developer so I'd be kind of OK with being the > maintainer - ofcourse only if you're fine with it. I'm fine with that. You've got more experience, whereas this is my first time contributing to a Debian package, so I reckon you should be the "Maintainer" of the package, if you're fine with it. Just a thought: should we get the Python and Golang teams involved, since both programming langs are being used and both dh buildsystems are being used? > > > * I suppose the maintenance of this package will keep getting messy due > > > to upstream mixing up two language build systems in a fairly > > > non-standard way. > > > I suppose it makes sense to ask upstream if they'd consider to switch > > > to something that eases maintenance burden on us
Bug#1055670: fwknop-server: must Depends: apparmor-profiles-extra
> The latest update breaks apparmor for the whole system. > > /etc/apparmor.d/usr.sbin.fwknopd: > include > > This must declare Depends: apparmor-profiles-extra. > > Otherwise the apparmor service can't parse the file and will refuse to start. Ah, that's annoying. I don't think I'll want to make fwknop-server require apparmor. I guess this means I need to reintroduce the fwknop-apparmor package. Thanks for flagging this. Francois -- https://fmarier.org/
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Hi Hilmar On 08/11/2023 08:36, Hilmar Preuße wrote: On 10/30/23 11:52, Hilmar Preuße wrote: Hi Stuart, I was told not to use that URL, so here is a new one https://freeshell.de/~hille42/debian_1054218/ Did you find the time to test the fix? Hilmar Thanks for the upload — I've been able to test it, having been autobuilt on the buildd, and I confirm it solves the bug on s390x. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1055677: ITP: monaspace -- An innovative superfamily of fonts for code
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: monaspace * URL : https://github.com/githubnext/monaspace/tree/main * License : OFL-1.1 Programming Lang: N/A Description : An innovative superfamily of fonts for code I'll maintain this under the fonts team. It is not easy to find a good coding font. This one looks great. The Monaspace type system: a monospaced type superfamily with some modern tricks up its sleeves. It is comprised of five variable axis typefaces. Each one has a distinct voice, but they are all metrics- compatible with one another, allowing you to mix and match them for a more expressive typographical palette. Thank you for using reportbug
Bug#1055633: libfilezilla: please exclude old TLS1.0 and TLS1.1 deprecated protocols during test
Control: forwarded -1 https://trac.filezilla-project.org/ticket/13005 Forwarded upstream for their information, see link above. Regards Phil -- Playing the game for the games sake. * Debian Maintainer Web: * Debian Wiki: https://wiki.debian.org/PhilWyett * Website: https://kathenas.org Social: * Instagram: kathenasorg * Threads: @kathenasorg signature.asc Description: This is a digitally signed message part
Bug#1055676: exports(5) man page does not document refer=
Package: nfs-common Version: 1:2.6.1-1 Severity: important BUG: exports(5) man page does not document refer= Possible text for exports(5) in the EXAMPLES section: --cut--cut--cut--cut-- To redirect an NFS mount from local machine /ref/baguette to /export/home/baguette on host 134.49.22.111 add this to Linux /etc/exports: /ref *(no_root_squash,refer=/export/home@134.49.22.111) --cut--cut--cut--cut-- Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
Bug#1055675: nfs-common: nfsref(8) binary missing
Package: nfs-common Version: 1:2.6.1-1 Severity: important nfs-common: nfsref(8) binary is missing. nfsref(8) is used to configure NFSv4 referrals, so access to a directory can be forwarded to another server. As Chuck Lever (NFS kernel maintainer) the refer= option in exports(5) is depreciated, and bullseye should ship nfsref(8) by default. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
Bug#1025218: marked as pending in python-urllib3
Hi Alexandre, On 10/11/2023 00:42, Alexandre Detiste wrote: I'm going 2 days at DebCamp Cambridge next week without planning Give me random things to do Thanks for your offer, after the upload (planned for the weekend). We should look at all the failing packages that depend on urrlib3... you could help on this if you want. IIRC there is a deploy of etherpad under debian.net, we could use it to coordinate. Cheers, -- Daniele Tricoli https://mornie.org
Bug#1025218: marked as pending in python-urllib3
Hi, On 10/11/2023 00:31, Daniele Tricoli wrote: Unfortunately tests just hangs somehow (I can reproduce on my chroot, but you can also see the pipeline on salsa). OK, no my fault! I was looking at the pipeline while running on my chroot and they are only slow: in this machine I was able to build in 18 minutes. Stefano, I had to enable verbose flag for pytest to just see that it was not hanging, I'm inclined to push the commit so I will not forget that some tests are actually slow. Thanks for your work on urllib3 packaging! :) -- Daniele Tricoli https://mornie.org
Bug#1053953: rust-indexmap: please upgrade to v2
preliminary analysis. upstream changelog: https://github.com/bluss/indexmap/blob/master/RELEASES.md nothing looks two scary forward dependencies: the new version of indexmap depends on the new version of hasbrown, and my attempts at relaxing have been unsuccesful, so it looks like we will need to do hashbrown first. reverse dependencies: The reverse dependency situation looks pretty good in general, details of individual packages below. btm - jonas package, already uses 2.x upstream. precious - jonas package, already uses 2.x upstream. python-maturin - non rust team package, has not bumped dependency upstream already rc buggy and not in testing rust-carapace-spec-clap - already uses 2.x upstream, debian package has dependency with no upper limit. rust-cargo - uses 2.x since upstream version 0.74, upstream made no code changes when bumping indexmap version. rust-cbindgen - upstream has not bumped but preliminary tests don't show any issues. rust-clap-3 - clap 3.x still uses indexmap 1 clap 4.x no longer uses indexmap, but that patch is too big to reasonablly backport. Preliminary tests with a bumped version seem ok. rust-gimli - upstream is on 2.x and appears to have bumped the dependency with no code changes (there are code changes in the commit, but they appear to relate to other dependency changes) rust-h2 - upstream git (not yet included in a release) is on 2.x and appears to have bumped the dependency with no code changes (there are code changes in the commit, but they appear to relate to other dependency changes) rust-laurel - non rust team package, upstream bumped dependency with no code changes. rust-petgraph - upstream already uses 2.x, debian package has no upper limit on dependency. rust-plist - upstream already uses 2.x rust-pyproject-toml - upstream already uses 2.x rust-quick-junit - upstream already uses 2.x rust-ron - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes (though there was a feature name change) rust-ruma-common - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-serde-with - upstream depends optionally on both versions 1.x and 2.x of indexmap. Debian currently disables the latter, looks like it needs to switch to disabling the former. rust-serde-yaml - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes (though there was a feature change) rust-sqlx-core - upstream uses 2.x, debian package has no upper limit on version. rust-toml-edit - upstream uses 2.x, debian package has no upper limit on version. rust-tre-command - upstream has not bumped but preliminary tests don't show any issues. rust-tree-sitter-cli - upstream has not bumped but preliminary tests don't show any issues. rust-configparser - upstream has not bumped but preliminary tests don't show any issues. rust-cookie-store - upstream has not bumped but preliminary tests don't show any issues. rust-elsa - upstream has not bumped but preliminary tests don't show any issues. rust-object - upstream dependency bumped with no code changes rust-py03 - upstream allows both versions 1.x and 2.x debian package has no upper limit on version. rust-rkyv - upstream has not bumped, tests pass after bumping dependency and adding std feature to it. rust-schemars - upstream has features for both versions of indexmap, currently the indexmap2 feature is disabled, no rdeps seem to depend on the indexmap feature rust-serde-json - upstream uses 2.x rust-toml - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-toml-0.5 - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-toml-edit - upstream uses 2.x in the latest (semver-breaking) version. The dependency bump was made with no code changes rust-tower - upstream has not bumped, test failures look no worse than before.
Bug#910247: python3-netgen: importing netgen.gui fails due to MPI_Comm_size()
Package: python3-netgen Version: 6.2.2006+really6.2.1905+dfsg-10 Followup-For: Bug #910247 As a workaround, initialise MPI before importing netgen.gui. > from mpi4py import MPI > import netgen.gui
Bug#1025218: marked as pending in python-urllib3
Hello Alexandre, On 07/11/2023 13:28, Alexandre Detiste wrote: Please release to experimental. (I ve build it myself and haven't seen problems yet) Unfortunately tests just hangs somehow (I can reproduce on my chroot, but you can also see the pipeline on salsa). I'm looking at this, and I will continue to spend time on this during the week. If I will not able to solve withing this weekend I plan to skip the hanging tests to make the upload (so I'm just asking to wait until this weekend) and then work on enable them again later. Thanks for your patience. Cheers, -- Daniele Tricoli https://mornie.org
Bug#1025218: marked as pending in python-urllib3
I'm going 2 days at DebCamp Cambridge next week without planning ;-) Give me random things to do ;-) Le ven. 10 nov. 2023 à 00:31, Daniele Tricoli a écrit : > > Hello Alexandre, > > On 07/11/2023 13:28, Alexandre Detiste wrote: > > Please release to experimental.
Bug#1055674: lspower: outputs \e instead of ESC symbol
Package: powermgmt-base
Version: 1.37
Severity: normal
Tags: patch
The lspower tool outputs \e instead of properly sending the ESC symbol.
Compare:
\e[0;1m✓ AC\e[0m
\e[0;32;1m+ BAT0 (98%)\e[0m
\e[0;1m✓ ucsi-source-psy-USBC000:001\e[0m
\e[0;1;30m✗ ucsi-source-psy-USBC000:002\e[0m
vs
✓ AC
+ BAT0 (98%)
✓ ucsi-source-psy-USBC000:001
✗ ucsi-source-psy-USBC000:002
The patch is attached.
--
With best wishes
Dmitry
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
-- no debconf information
--- a/lspower 2023-11-10 01:14:04.094500300 +0200
+++ b/lspower 2023-11-10 01:14:09.022530391 +0200
@@ -50,7 +50,7 @@
C2="\e[0m"
fi
- echo "$C1$ICON $x${CAPACITY:+ ($CAPACITY%)}${HEALTH:+ $HEALTH}$C2"
+ echo -e "$C1$ICON $x${CAPACITY:+ ($CAPACITY%)}${HEALTH:+ $HEALTH}$C2"
done
if [ -z "$ICON" ];then echo "No powers supply sensors; that's normal on a
desktop.";fi
Bug#1055673: libxml2: changes semantic on DTD reformatting
Package: libxml2 Version: 2.9.10+dfsg-6.7+deb11u4 Severity: minor X-Debbugs-Cc: t...@mirbsd.de Control: affects -1 xmlstarlet $ cat test.xml ]> baz $ xmlstarlet fo test.xml ]> baz $ xmllint test.xml ]> baz libxml2 here changes the (bar+) to (bar)+ which is syntactically identical but not semantically (it’s still a sequence of bar+ and might be extended, in the future, to (bar+, baz*) or something). -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-24-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libxml2 depends on: ii libc6 2.31-13+deb11u7 ii libicu67 67.1-7 ii liblzma5 5.2.5-2.1~deb11u1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 libxml2 recommends no packages. libxml2 suggests no packages. -- no debconf information
Bug#1055672: Depends on python3-typed-ast, which has been removed from testing and unstable due to #1051802
Package: prospector Version: 1.1.7-4 Severity: serious X-Debbugs-Cc: daniel.leid...@ext.secunet.com The package declares a dependency on python3-typed-ast. However, due to #1051802, this package is no longer available. It is my understanding that python3-typed-ast has been superseeded by the "ast" standard library in Python 3.8+. Thus, prospector is currently uninstallable. Regards, Daniel -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prospector depends on: ii dodgy 0.1.9-5 ii libjs-sphinxdoc7.2.6-2 ii pylint 2.17.4-1 ii python33.11.4-5+b1 ii python3-astroid2.15.6-1 ii python3-mccabe 0.7.0-1 ii python3-mypy 1.6.1-1 ii python3-pep8-naming0.10.0-2 ii python3-pycodestyle2.10.0-1 ii python3-pydocstyle 6.3.0-1 ii python3-pyflakes 2.5.0-1 ii python3-pylint-celery 0.3-7 ii python3-pylint-django 2.0.13-3 ii python3-pylint-flask 0.5-5 ii python3-pylint-plugin-utils0.7-3 ii python3-pyroma 2.6b2-1 ii python3-requirements-detector 0.6-4 ii python3-setoptconf 0.3.0-2 ii python3-typed-ast 1.5.4-1+b1 ii python3-yaml 6.0.1-1 Versions of packages prospector recommends: ii vulture 2.7-1 prospector suggests no packages. -- no debconf information
Bug#1055671: rust-reqwest should enable rustls support on all architectures
Source: rust-reqwest Version: 0.11.22-2 Severity: normal ring is now built on all release architectures.
Bug#1040378: qemu.desktop: invalid desktop file
Package: qemu-system-data Version: 1:8.1.2+ds-1 Followup-For: Bug #1040378 X-Debbugs-Cc: t...@mirbsd.de But what *is* its purpose then? -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) -- no debconf information
Bug#1055630: cfitsio: Please forward patches upstream
Hi, On 2023-11-09 09:41, Ole Streicher wrote: > Source: cfitsio > Version: 4.3.0-2 > Severity: wishlist > > Dear maintainer, > > HEASARC now maintains CFITSIO in Github: > > https://github.com/HEASARC/cfitsio > > In the adass2023 Slack, they encouraged to submit patches to the repository, > finally moving to an open development philosophy. > > As there are few patches in the Debian package which may be useful upstream: > could they be reviewed and forwarded if applicable? All the patches relevant for upstream have already been forwarded upstream, some of them have been applied, some of them not. I'll also reported them to github. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1054919: kaccounts-providers: google authentication hang after username entry
On 09/11/2023 03:04, Nicholas D Steeves wrote: Hi, I received a report from sney (in #debian-qt-kde on OFTC) that a workaround is no longer necessary in either kaccounts-providers or signon-ui. Thus it sounds like this was a case #1 problem (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#24) 1. Google refuses to talk to Qt webkit/QtWebEngine that identifies itself accurately. and it appears that they've reverted the action that broke everyone's access to their Google accounts. This is the most correct solution and the best possible outcome. Alexis and Peter, would you please confirm that the workaround is no longer necessary? And please leave the bug open even if Google accounts are working again, because the frequency of this breakage has been mounting. Yes it works again now (with the workaround removed). I can login into my google account. I found where I got this workaround, this is what has done dabiswas112 in a fedora COPR in hazel-bunny/ports: https://github.com/hazel-bunny/rpm-packaging/blob/master/lib/signon/signon-ui/fake-user-agent.patch This COPR was suggested here: https://bugzilla.redhat.com/show_bug.cgi?id=2230099. -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F |
Bug#1055670: fwknop-server: must Depends: apparmor-profiles-extra
Package: fwknop-server Version: 2.6.10-18 Severity: serious Tags: patch security Justification: Policy 7.2 X-Debbugs-Cc: Debian Security Team Dear Maintainer, The latest update breaks apparmor for the whole system. /etc/apparmor.d/usr.sbin.fwknopd: include This must declare Depends: apparmor-profiles-extra. Otherwise the apparmor service can't parse the file and will refuse to start. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwknop-server depends on: ii init-system-helpers 1.65.2 ii iptables 1.8.9-2 ii libc62.37-12 ii libfko3 2.6.10-18 ii libpcap0.8 1.10.4-4 fwknop-server recommends no packages. fwknop-server suggests no packages. -- Configuration Files: /etc/fwknop/access.conf [Errno 13] Permission denied: '/etc/fwknop/access.conf' /etc/fwknop/fwknopd.conf [Errno 13] Permission denied: '/etc/fwknop/fwknopd.conf' -- no debconf information
Bug#1055669: bcftools: test_vcf_merge failures on armhf: Bus error
Source: bcftools Version: 1.18-1 Severity: serious Tags: ftbfs Justification: ftbfs Control: forwarded -1 https://github.com/samtools/bcftools/issues/2036 Dear Maintainer, bcftools currently ftbfs on armhf due to multiple test_vcf_merge failures with Bus error[1]. I already informed upstream[2]. This bug is mostly to keep track of the issue on Debian side and eventually comment on possible Debian specific workarounds. For the context, there are 44 failure looking typically like: test_vcf_merge: /<>/bcftools merge --no-version -Ob --force-samples -0 /tmp/YVqRgiAYOP/merge.a.vcf.gz /tmp/YVqRgiAYOP/merge.b.vcf.gz /tmp/YVqRgiAYOP/merge.c.vcf.gz | /<>/bcftools view --no-version | grep -v ^##bcftools_ Non-zero status 1 Failed to read from standard input: unknown file type .. failed ... [1]: https://buildd.debian.org/status/fetch.php?pkg=bcftools=armhf=1.18-1=1699434189=1 [2]: https://github.com/samtools/bcftools/issues/2036 For information, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Silent Voices - Humancradlegrave signature.asc Description: PGP signature
Bug#1055668: optipng: CVE-2023-43907
Source: optipng Version: 0.7.7-3 Severity: important Tags: security upstream fixed-upstream Forwarded: https://sourceforge.net/p/optipng/bugs/87/ X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 0.7.7-2 Control: found -1 0.7.7-1 Hi, The following vulnerability was published for optipng. CVE-2023-43907[0]: | OptiPNG v0.7.7 was discovered to contain a global buffer overflow | via the 'buffer' variable at gifread.c. The issue is fixed in 0.7.8 upstream. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-43907 https://www.cve.org/CVERecord?id=CVE-2023-43907 [1] https://sourceforge.net/p/optipng/bugs/87/ [2] https://optipng.sourceforge.net/ Regards, Salvatore
Bug#1055667: nextpnr: prevent testing migration when embedded chipdbs are out-of-date
Source: nextpnr Severity: wishlist X-Debbugs-Cc: d...@darkboxed.org s...@debian.org Note to self, we should find a way to prevent testing migration of FPGA description packages (fpga-icestorm/apycula/prjtrellis) when nexpnr still embeds older version in it's chipdb binpkgs. Autopkgtests in the decriptor packages that fail when this is the case would probably work. Any other ideas welcome. --Daniel
Bug#1055666: coreutils: date man page does not have an ENVIRONMENT section mentioning TZ
Package: coreutils Version: 8.32-4+b1 Severity: minor Hi, I notice that the date(1) man page has no ENVIRONMENT section. It would be useful to have an ENVIRONMENT section that documents the effect of the TZ variable on the date output. Note that there is an example of using TZ in the EXAMPLES section. -- System Information: Debian Release: 11.8 APT prefers oldstable-security APT policy: (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages coreutils depends on: ii libacl1 2.2.53-10 ii libattr1 1:2.4.48-6 ii libc62.31-13+deb11u7 ii libgmp10 2:6.2.1+dfsg-1+deb11u1 ii libselinux1 3.1-3 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#1042406: dh-r: throws "Use of uninitialized value $dep_line in substitution" warnings with some packages
On Thu, 27 Jul 2023 22:07:23 +0200 Andreas Tille wrote:
> Am Thu, Jul 27, 2023 at 11:51:42PM +0530 schrieb Nilesh Patra:
> >
> > On checking further, it seems to be stemming from the recommends line in
> > dh-r code[1]. This is because recommendsinput variable is being directly
> > set from desc->{Recommends}, and a check of whether this field is empty
> > is *after* the said initialization[3]. This can lead to `recommendsinput`
> > being set as `undef` and hence the unintialized errors from debhelper.
>
> That's a pretty sensible explanation for the problem.
>
> > The reason that we don't see such problems in for instance
> > r-bioc-bsgenome is because it has some values in the testdepends and
> > recommendsinput ends up having some value[4].
> >
> > I have attached a patch to fix this, please check.
>
> While reading the patch it definitely fixes the uninitialized value.
> However, it does not fulfill the intended behaviour to add the
> Test-Depends as Recommends. I'm considering parsing DESCRIPTION
> directly to do so.
>
> > ** Please test properly before you merge and upload, do NOT upload
> > blindly **
>
> Thanks a lot for the warning. I'll leave the bug open as a reminder
> and will sleep over it for a couple of nights to decide what might be
> the best solution for the problem.
I guess it has been a little bit longer than a couple of nights since
the bug report :)
We digressed discussing adding test depends as recommends - which was
not the purpose of this bug or even patch. It was rather to fix a
warning that dh-r spews sometimes and AFAICS, there is no regression.
have you thought about merging or rejecting the patch yet?
> > PS: Please mention my contribution in d/ch if you take this patch.
>
> Sure. ;-)
Best,
Nilesh
signature.asc
Description: PGP signature
Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge
Package: usr-is-merged Version: 38 Severity: important X-Debbugs-Cc: d...@darkboxed.org Hi Marco, usr-is-merged=38 errors out in my unstable chroot since it's not merged yet, but this error also seems to prevent installing usrmerge: ``` (unstable-amd64)root@Janet:~# apt-get full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: libfile-find-rule-perl libnumber-compare-perl libtext-glob-perl Use 'apt autoremove' to remove them. The following packages will be upgraded: usr-is-merged 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/5504 B of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 11489 files and directories currently installed.) Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) (unstable-amd64)root@Janet:~# apt-get install usrmerge Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: usr-is-merged The following NEW packages will be installed: usrmerge The following packages will be upgraded: usr-is-merged 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/18.5 kB of archives. After this operation, 39.9 kB of additional disk space will be used. Do you want to continue? [Y/n] debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 11489 files and directories currently installed.) Preparing to unpack .../usr-is-merged_38_all.deb ... ** * * The usr-is-merged package cannot be installed because this system does * not have a merged /usr. * * Please install the usrmerge package to convert this system to merged-/usr. * * For more information please read https://wiki.debian.org/UsrMerge. * ** dpkg: error processing archive /var/cache/apt/archives/usr-is-merged_38_all.deb (--unpack): new usr-is-merged package pre-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Thanks, --Daniel
Bug#1055626: cabal-install: pkg-config package gtk4-any, not found in the pkg-config database
Control: tags -1 unreproducible Hi! On Thu, Nov 09, 2023 at 04:01AM, Elizaveta L. wrote: > When I try to install gi-gtk-4.0.8 I get the following error > > ``` > Resolving dependencies... > Error: cabal: Could not resolve dependencies: > [__0] next goal: gi-gtk (user goal) > [__0] rejecting: gi-gtk-4.0.8 (conflict: pkg-config package gtk4-any, not > found in the pkg-config database) > [__0] rejecting: gi-gtk-4.0.6, gi-gtk-4.0.5, gi-gtk-4.0.4, gi-gtk-4.0.3, > gi-gtk-4.0.2, gi-gtk-4.0.1, gi-gtk-3.0.41, gi-gtk-3.0.39, gi-gtk-3.0.38, > gi-gtk-3.0.37, gi-gtk-3.0.36, gi-gtk-3.0.35, gi-gtk-3.0.34, gi-gtk-3.0.33, > gi-gtk-3.0.32, gi-gtk-3.0.31, gi-gtk-3.0.30, gi-gtk-3.0.29, gi-gtk-3.0.28, > gi-gtk-3.0.27, gi-gtk-3.0.26, gi-gtk-3.0.25, gi-gtk-3.0.24, gi-gtk-3.0.23, > gi-gtk-3.0.22, gi-gtk-3.0.21, gi-gtk-3.0.20, gi-gtk-3.0.19, gi-gtk-3.0.18, > gi-gtk-3.0.17, gi-gtk-3.0.16, gi-gtk-3.0.15, gi-gtk-3.0.14, gi-gtk-3.0.13, > gi-gtk-3.0.12, gi-gtk-3.0.11, gi-gtk-3.0.10, gi-gtk-3.0.9, gi-gtk-3.0.8, > gi-gtk-3.0.7, gi-gtk-3.0.6, gi-gtk-3.0.5, gi-gtk-3.0.4, gi-gtk-3.0.3, > gi-gtk-3.0.2, gi-gtk-3.0.1, gi-gtk-0.3.18.15, gi-gtk-0.3.18.14, > gi-gtk-0.3.18.13, gi-gtk-0.3.18.12, gi-gtk-0.3.16.12, gi-gtk-0.3.18.10, > gi-gtk-0.3.16.11, gi-gtk-0.3.16.10, gi-gtk-0.3.16.9, gi-gtk-0.3.16.8 > (constraint from user target requires ==4.0.8) > [__0] fail (backjumping, conflict set: gi-gtk) > After searching the rest of the dependency tree exhaustively, these were the > goals I've had most trouble fulfilling: gi-gtk > ``` > > Apt says that `libgtk-4-dev is already the newest version (4.12.3+ds-2)`. I tried this in a clean unstable environment and cannot reproduce it. Here is what I did: $ docker run --rm -ti debian:sid # apt update # apt upgrade -y # apt install -y cabal-install pkg-config libgtk-4-dev libatk1.0-dev # cabal update # cabal get gi-gtk-4.0.8 # cd gi-gtk-4.0.8 # cabal build The above builds gi-gtk-4.0.8 successfully. Maybe something is wrong with your environment? Best, -- Ilias
Bug#1054689: therion: FTBFS: utest-proj.cxx:1:10: fatal error: catch2/catch.hpp: No such file or directory
On Thu, Nov 9, 2023 at 3:14 AM Wookey wrote: > On 2023-11-08 20:10 +0100, Martin Budaj wrote: > > as we still need to maintain Catch2 v2 API compatibility to run CI tests > > and builds on older Ubuntu images, we can't simply migrate to v3. > > Who is building 'latest' Therion on old Ubuntu? And are they getting > their sources from the Debian unstable package? Or from Upstream? GitHub Actions has Ubuntu 20.04 and 22.04 images: https://github.com/actions/runner-images We use it to run CI tests and to build the official installer. > > For now, I'll just enable using the bundled Catch2 instead of v3 installed > > in the system. > > That's not the right approach for the Debian package, and this bug is about > the debian package. > Debian unstable has catch 3 in it. We should use it, not an old bundled > catch2 copy. > Upstream builds and Ubuntu builds can do something different if need > be but that's not a good reason for the Debian package not to > DTRT. And in general I'd expect current Ubuntu to have catch3 too so > using the system version will be appropriate there too. Sure, but to do it properly takes more time then I could currently dedicate to this, as more changes are required: - adapt the C++ sources to Catch v3 - introduce #ifs to C++ sources to switch between bundled and system headers, as v3 names them differently - modify make and cmake build systems to handle this switching I plan to do it when time allows (upstream), but for now I think that it's better to have a workaround than nothing. Best wishes Martin
Bug#1055505: [pysam-developers/pysam] Incompatible with Python 3.12 (Issue #1242)
Hi, quoting upstream in the related issue: - Weitergeleitete Nachricht von John Marshall - The linked build log indicates that a version of Cython that is not compatible with Python 3.12 has been used. -- Reply to this email directly or view it on GitHub: https://github.com/pysam-developers/pysam/issues/1242#issuecomment-1803678762 You are receiving this because you authored the thread. Message ID: - Ende weitergeleitete Nachricht - -- http://fam-tille.de
Bug#1055664: rebuild fails with node-typescript 4.9.5 in experimental
Package: node-vscode-lsp
Version: 1.0.0~git20230424.1320922-2
Severity: important
User: debian...@lists.debian.org
Usertags: typescript495
Hi,
This package's rebuild failed with node-typescript 4.9.5 currently in
experimental.
node-typescript 4.9.5 is planned to be uploaded to unstable in about two
weeks to
one month time, so please make sure this package will be ready for it.
The severity
of this bug will be raised to serious after node-typescript 4.9.5 is
uploaded to unstable.
Relevant errors;
make[1]: Entering directory '/<>'
echo "# Compiling types"
# Compiling types
cd types && tsc -p src
set -e; for p in jsonrpc protocol server; do \
echo "# Compiling $p"; \
(cd $p && tsc -p src/common && tsc -p src/node && tsc -p
src/browser); \
done
# Compiling jsonrpc
src/common/encoding.ts(123,8): error TS2845: This condition will always
return 'true'.
make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:10: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
Full build log is attached.
--
PGP: BC55 8A19 E57C 716D D12F 2FA2 EEED 479E 6CEC F707
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on operator
+=+
| node-vscode-lsp 1.0.0~git20230424.1320922-2 (amd64) Mon, 06 Nov 2023 22:53:31 + |
+=+
Package: node-vscode-lsp
Version: 1.0.0~git20230424.1320922-2
Source Version: 1.0.0~git20230424.1320922-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full
I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-59e3509a-fd55-42c7-80d3-740e84323771' with '<>'
Copying /home/weepingclown/debian/js/typescript/node-typescript_4.9.5+ds1-1_all.deb to Sbuild::ChrootSchroot=HASH(0x562856c73378)->get('Location')...
I: NOTICE: Log filtering will replace 'build/node-vscode-lsp-jYuHMA/resolver-iDP9AH' with '<>'
+--+
| Update chroot|
+--+
Get:1 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ InRelease
Ign:1 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ InRelease
Get:2 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ Release [603 B]
Get:2 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ Release [603 B]
Get:3 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ Release.gpg
Ign:3 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ Release.gpg
Get:4 file:/build/node-vscode-lsp-jYuHMA/resolver-fY5eHl/apt_archive ./ Packages [980 B]
Get:5 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Fetched 779 kB in 3s (309 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
The following packages will be upgraded:
fakeroot libdb5.3 libfakeroot linux-libc-dev
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2815 kB of archives.
After this operation, 35.8 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 libdb5.3 amd64 5.3.28+dfsg2-3 [697 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 libfakeroot amd64 1.32.2-1 [29.1 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 fakeroot amd64 1.32.2-1 [73.9 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 linux-libc-dev amd64 6.5.10-1 [2016 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 2815 kB in 1s (3466 kB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading
Bug#1055662: rust-proc-macro2: build-depends on missing package librust-proc-macro2-1+proc-macro-dev
Source: rust-proc-macro2 Version: 1.0.65-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 build-depends on missing package librust-proc-macro2-1+proc-macro-dev -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVNJc4ACgkQLHwxRsGg ASFk+A//Z+2wMdY7QR3oDEfT/2+dS8QbYT+J9Uk9f+JCQIqotQRqLf96OL+3r8HU +kpf1LOtBJ0nKdiliGZkO6vrAn/Qw2iMD2PBTcWzhUvRU1kpO1tcXZy8EyuZ0Pdu Z9t58seLJVwpD22rq5dcGtARPVzn3fTcb9lgopNbqyh6rHkUZ4Q/hEMIsY0z2Xt7 WV0GpwdmE09Y2+SfO1fbCpXdNzDwUh/33GV1tU5XTK2XaJHucJu5+cDtn4vDfNfK LMRyfjPeSBCLCJ7+k77tnjlh5KMG9fYdfyBRFvhnT2B6bT4d4P4upno/vwZ9BX5T 4DE3mEFTWO+PesGO6KzIU7ks+1MgbnVZO7PZNPyzXza7D2dlOajZc7r3TnjHzaGF g3s5bZXjauOkypbE6utuiOhJ2xPB7ore+eK2AawyAizpQxea8ISsogyen7XOqbGd rVKRTapWDfzMbXmtH2y29QjG1pbirB2NaCP4JmHUKIhGo1hofv8ei32a4Vkc59Pl 0HuI5d3gqD5HrroT82pXuF1VfNxHZPMiXzc3xNftAgPq18clOA8niSZq5dadaC1a FrFFyiozTRh3z0ebQ+/7Y6tZWh/uRMiXaTaHgyvb767HTMTn7TX1loVME51w/v0D epnbvAwxOard0sdtvwsIGKP+Nv3cBRfUIsRk7AQDTIEzYj2T0NQ= =9G7E -END PGP SIGNATURE-
Bug#1055663: rust-syn: build-depends on missing package librust-proc-macro2-1+proc-macro-dev
Source: rust-syn Version: 2.0.26-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 build-depends on missing package librust-proc-macro2-1+proc-macro-dev -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVNJhkACgkQLHwxRsGg ASGrug//d6DvX2AJD28nncKM56m2ISY7zzz31HNvzmbfuAXJ3fMZ24zGCXJKjaiQ 68w3C1Te3cczJvlzuD37G7aG3ZSYSVfv5BH1MYoHnuxRC19DWJfglbB5Z/sIx1He QO9G0FuFNyrzmEsB04zDSevK56Fx30nMb81jpCpgEp0fNjjn1Wt6R6Njfg9ab9q0 WMk4AlTGvkjCMTRKqlGhKGAJaspN1ZazQi+BdN/CSWkj/m2vfVyUtmxoJUYyQ5EJ dxL0kzScXySnXgzq1D90qPSMYP6FDhj66BBAp0q0FWJRIsz73gclLQreLQQveH/c 5NMdBzPs7zs9Z9DEzw+n1C7TVvRhsD+z601XyJdBUdwZxL0aespQz8AYYWigwoYw gv6dqmZ1mOPw18ZRRKhDq1f6bkxneeAJS0waaM4tTN0F7VF+WYzUF4IfMp3tz0q+ xBDrqwk70GfHgvFW4xf/VSkSiRSZpLK4gBo/hSbrts2yT14OC3YrtP+gaCB7pTmI RMZ1hY9C4JYvkSTy7N7miD3h8UGiZieLaoliHSBj75dVah9EoTbJ8reXJmMuydRb tBr90dJOiKP9soyfpS7m1Amcjm5+kQuGr9o9btrz2Q7jRvt5rpmmHY0t9IMWj+3m z87dnWb697h1h4GT7oZQldnraZEU459+tgAP31NXM4Sjmh82kQ8= =SlJm -END PGP SIGNATURE-
Bug#1055661: rebuild fails with node-typescript 4.9.5 in experimental
Package: node-socks
Version: 2.7.1+dfsg-2
Severity: important
User: debian...@lists.debian.org
Usertags: typescript495
Hi,
This package's rebuild failed with node-typescript 4.9.5 currently in
experimental.
node-typescript 4.9.5 is planned to be uploaded to unstable in about two
weeks to
one month time, so please make sure this package will be ready for it.
The severity
of this bug will be raised to serious after node-typescript 4.9.5 is
uploaded to unstable.
Relevant errors;
Found debian/nodejs/./build
cd ./. && sh -ex debian/nodejs/./build
+ tsc -p .
src/common/helpers.ts(194,53): error TS2339: Property 'ipaddress' does
not exist on type 'never'.
dh_auto_build: error: cd ./. && sh -ex debian/nodejs/./build returned
exit code 2
make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
Full build log is attached.
--
PGP: BC55 8A19 E57C 716D D12F 2FA2 EEED 479E 6CEC F707
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on operator
+==+
| node-socks 2.7.1+dfsg-2 (amd64) Mon, 06 Nov 2023 22:47:46 + |
+==+
Package: node-socks
Version: 2.7.1+dfsg-2
Source Version: 2.7.1+dfsg-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full
I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-74f7311b-416d-44bf-bc4a-5ed2fe874b0f' with '<>'
Copying /home/weepingclown/debian/js/typescript/node-typescript_4.9.5+ds1-1_all.deb to Sbuild::ChrootSchroot=HASH(0x5588c7b871f8)->get('Location')...
I: NOTICE: Log filtering will replace 'build/node-socks-6AASsn/resolver-xBMIW4' with '<>'
+--+
| Update chroot|
+--+
Get:1 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ InRelease
Ign:1 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ InRelease
Get:2 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ Release [603 B]
Get:2 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ Release [603 B]
Get:3 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ Release.gpg
Ign:3 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ Release.gpg
Get:4 file:/build/node-socks-6AASsn/resolver-qcdMrr/apt_archive ./ Packages [980 B]
Get:5 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Fetched 779 kB in 3s (284 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
The following packages will be upgraded:
fakeroot libdb5.3 libfakeroot linux-libc-dev
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2815 kB of archives.
After this operation, 35.8 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 libdb5.3 amd64 5.3.28+dfsg2-3 [697 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 libfakeroot amd64 1.32.2-1 [29.1 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 fakeroot amd64 1.32.2-1 [73.9 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 linux-libc-dev amd64 6.5.10-1 [2016 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 2815 kB in 1s (5482 kB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 11493 files and directories currently installed.)
Preparing to unpack .../libdb5.3_5.3.28+dfsg2-3_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28+dfsg2-3) over (5.3.28+dfsg2-2) ...
Setting up libdb5.3:amd64 (5.3.28+dfsg2-3)
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi, I confirm that Google authentication and gdrive now work without using hacks. Best regards Peter
Bug#1050446: nfs over rdma between debian12 client and debian11 server can cause data corruption
Severity: wishlist We run more tests, and observed that pgrading the storage server to Debian12(/bookwork solves the issue. The storage server can be accessed through rdma from debian11 and 12. That means, the problem occurs only when the storage server is on debian11, the client is on debian11 mounted with proto=rdma. This information is good enough for us, as we'll upgrade first the storage server. Another workaround is to switch to proto=tcp As this issue (proto=rdma from debian12 client to debian11 server) is difficult to fix and a workaround exists, I'll downgrade the severity.
Bug#1055656: bookworm-pu: package ms-gsl/4.0.0-2+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
[ Reason ]
The libmsgsl-dev package in stable is currently incompatible with std::variant
from GNU's libstdc++. To solve this issue, I propose a patch adding conditional
noexcept for the gsl::not_null template constructors.
[ Impact ]
My fix is necessary for backporting the newer versions of the telegram-desktop
package to the bookworm release. This is merely a bug fix so it should go to
stable-updates as per policy. https://backports.debian.org/Contribute/#index1h3
[ Tests ]
Manual. Published and viewed stories in Telegram Desktop.
[ Risks ]
Little. This header-only library has only one dependant, and for the changes to
be effective, the dependant package is need to be rebuilt.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Only single new patch with the fix and autotests. For convenience, you can
review the difference in our GitLab.
https://salsa.debian.org/debian/ms-gsl/-/compare/debian%2Fmaster...debian%2Fbookworm
[ Other info ]
Additional information can be obtained from the related bug reports here, in
Debian bug tracker, and on GitHub.
diffstat for ms-gsl-4.0.0 ms-gsl-4.0.0
changelog|6 +
patches/Mark-gsl-not_null-constructors-as-noexcept.patch | 60 +++
patches/series |1
3 files changed, 67 insertions(+)
diff -Nru ms-gsl-4.0.0/debian/changelog ms-gsl-4.0.0/debian/changelog
--- ms-gsl-4.0.0/debian/changelog 2022-02-05 23:19:23.0 +0300
+++ ms-gsl-4.0.0/debian/changelog 2023-11-09 20:07:33.0 +0300
@@ -1,3 +1,9 @@
+ms-gsl (4.0.0-2+deb12u1) bookworm; urgency=medium
+
+ * New Mark-gsl-not_null-constructors-as-noexcept.patch (Closes: #1051289)
+
+ -- Nicholas Guriev Thu, 09 Nov 2023 20:07:33 +0300
+
ms-gsl (4.0.0-2) unstable; urgency=medium
* Ignore -Wpsabi warnings on PowerPC.
diff -Nru ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch
--- ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch 1970-01-01 03:00:00.0 +0300
+++ ms-gsl-4.0.0/debian/patches/Mark-gsl-not_null-constructors-as-noexcept.patch 2023-11-08 17:00:49.0 +0300
@@ -0,0 +1,60 @@
+Description: Mark gsl::not_null constructors as noexcept when underlying type can be moved with no exception
+Bug-GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106547
+Bug-Debian: https://bugs.debian.org/1051289
+Forwarded: https://github.com/microsoft/GSL/pull/1135
+Author: Nicholas Guriev
+Last-Update: Tue, 05 Sep 2023 23:00:33 +0300
+
+--- a/include/gsl/pointers
b/include/gsl/pointers
+@@ -87,19 +87,19 @@ public:
+ static_assert(details::is_comparable_to_nullptr::value, "T cannot be compared to nullptr.");
+
+ template ::value>>
+-constexpr not_null(U&& u) : ptr_(std::forward(u))
++constexpr not_null(U&& u) noexcept(std::is_nothrow_move_constructible::value) : ptr_(std::forward(u))
+ {
+ Expects(ptr_ != nullptr);
+ }
+
+ template ::value>>
+-constexpr not_null(T u) : ptr_(std::move(u))
++constexpr not_null(T u) noexcept(std::is_nothrow_move_constructible::value) : ptr_(std::move(u))
+ {
+ Expects(ptr_ != nullptr);
+ }
+
+ template ::value>>
+-constexpr not_null(const not_null& other) : not_null(other.get())
++constexpr not_null(const not_null& other) noexcept(std::is_nothrow_move_constructible::value) : not_null(other.get())
+ {}
+
+ not_null(const not_null& other) = default;
+--- a/tests/notnull_tests.cpp
b/tests/notnull_tests.cpp
+@@ -24,6 +24,7 @@
+ #include // for uint16_t
+ #include // for basic_string, operator==, string, operator<<
+ #include // for type_info
++#include// for variant, monostate, get
+
+ #include "deathTestCommon.h"
+ using namespace gsl;
+@@ -489,6 +490,17 @@ TEST(notnull_tests, TestNotNullConstruct
+ }
+ #endif
+ }
++
++TEST(notnull_tests, TestVariantEmplace)
++{
++int i = 0;
++std::variant> v;
++v.emplace>();
++
++EXPECT_FALSE(v.valueless_by_exception());
++EXPECT_TRUE(v.index() == 1);
++EXPECT_TRUE(std::get<1>(v) == );
++}
+ #endif // #if defined(__cplusplus) && (__cplusplus >= 201703L)
+
+ TEST(notnull_tests, TestMakeNotNull)
diff -Nru ms-gsl-4.0.0/debian/patches/series ms-gsl-4.0.0/debian/patches/series
--- ms-gsl-4.0.0/debian/patches/series 2022-02-03 18:42:25.0 +0300
+++ ms-gsl-4.0.0/debian/patches/series 2023-11-08 17:00:49.0 +0300
@@ -1 +1,2 @@
+Mark-gsl-not_null-constructors-as-noexcept.patch
PowerPC-warn-suppression.patch
signature.asc
Description: This is a digitally
Bug#1055502: liblcms2-2: Please build the fast-float and threaded plugins
Update: I hadn't considered that the main codebase is MIT licenced, so the way to do this without mixing licences within a package would be to generate a lcms2 package and a separate lcms2-plugins-gpl package, each with their own -dev packages with the necessary header files.
Bug#1052397: poco: Please update to new upstream release 1.12.4 in experimental
Dear maintainers, dear all, A small reference counting issue [0] has been found in Poco < 1.12 that result in memory corruption. This is often benign as it tend to happen during program exit, but I have noticed coredumpctl dutifully taking note of the situation each time I run an affected program. I hope this provides another reason to consider the upgrade worth it. Thank you very much. [0]: https://github.com/pocoproject/poco/issues/3507
Bug#1055651: mirror submission for mirror.dhakacom.com
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.dhakacom.com Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 mips mips64el mipsel powerpc ppc64el riscv64 s390x Archive-http: /debian/ Archive-rsync: debian/ Maintainer: http://mirror.dhakacom.com/debian Country: BD Bangladesh Location: http://mirror.dhakacom.com/debian Trace Url: http://mirror.dhakacom.com/debian/project/trace/ Trace Url: http://mirror.dhakacom.com/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.dhakacom.com/debian/project/trace/mirror.dhakacom.com
Bug#1055494: closed by Debian FTP Masters (reply to Sebastian Andrzej Siewior ) (Bug#1055494: fixed in clamav 1.2.1+dfsg-2)
Control: reopen -1 On 07/11/2023 22.27, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the clamav-doc package: #1055494: clamav-doc: missing Breaks+Replaces: clamav (<< 1.2) There is no file conflict between clamav-docs in sid (ships everything in /usr/share/doc/clamav-docs/) and clamav-doc in experimental (ships most bits in /usr/share/doc/clamav/), but between clamav/sid and clamav-doc/experimental, and only on /usr/share/doc/clamav/README.Debian.gz Andreas
Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal
On Fri, Nov 10, 2023 at 12:05:20AM +0800, Maytham Alsudany wrote: > On Thu, 2023-11-09 at 00:32 +0530, Nilesh Patra wrote: > > > On the contrary, avoiding the use of dh-golang as done in this repo[3] > > > causes > > > all the tests to pass without problem, and I'm unsure to why that is. > > > > This was due to some caveats with the build system and also how > > dh_golang works. We added in a patch that'd skip running gen-go-code.py > > and this was being used at more than one place. > > Doesn't the update_go_generated_files function in setup.py[6] run gen-go- > code.py, specifically `kitty +launch gen-go-code.py`? Patch#0003[7] adds the > `return` statement right afterwards. Yeah, that was a mis-type from my end. I meant to say "build_static_kittens" function instead from where we are returning and building the kitten binary on our own. The line: `"HOME="$(HOME)" KITTY_RUNTIME_DIRECTORY="$(KITTY_RUNTIME_DIRECTORY)" python3 setup.py $(V) build-launcheri` in the tests in d/rules calls "build_static_kittens(args, launcher_dir=launcher_dir)" and this seems to build the kittens binary 'again' in kitty/launcher which did not work for us because we patched out the function altogether. What I did to get around this is to simply symlink the already created kittens binary - that got the python tests passing. Let me know if this is still unclear. > > > We may have to take the approach Fedora has taken, where they've skipped > > > any > > > continuously failing tests[4]. > > > > For now I disabled two tests in the go code that tries to fiddle with > > proc/devfs and can potentially fail in a chroot. Python tests probably > > also try to do some non-standard stuff and we could disable it later if > > it goes flaky on the buildd machines. > > If we have time, it's probably good to get to the bottom of these flaky tests > and patch them instead of skipping them outright. I did not dig very deep but I have some pointers. The two go tests skipped are: * TestCreateAnonymousTempfile - my *hunch* this very likely fails due to it trying to do $things with procfs. This test does not fail for me in my base system but rather in a chroot. * TestHintMarking - I am not sure why this fails but I observed the failure even when I tried in the upstream repo. Not 100% sure if I ran it the right way but since it failed anyway, I considered skipping it. I hope that provides some justification. > This may involve filing bug reports upstream, and > creating PRs when necessary upstream in order to improve > their test suites for both Python and Golang. Agreed, and I would love some coordination/help with this bit. > > That said, I want to discuss/ask a few things: > > * Can you take a look at my commits and let me know if you have any > > comments? > > Regarding commit 38ea7407: > This is a nitpick (and I think this is a mistake): should the patch file end > with .patch instead of .py? This was an oversight at my end - fixed - Thanks. > It would probably be beneficial if we could setup the gbp workflow by hand, > ensuring the upstream branch is up to date Not sure what you mean here. `gbp import-orig` takes care of it. > and setting up a patch-queue/debian/(unstable|experimental) branch. No, please. These are never really meant to be pushed. Besides people use different way to apply patches - I use quilt and not `gbp pq`. > Regarding commit d847dbfe: > The d/ch entry needs some cleaning up, with the merging and removal of some > points. (I'm assuming you used `gbp dch`.) > > For example, > > * patch: make setup.py compatible with GOPATH mode > is probably not something the end user needs to know about. But we (as maintainers) do. I also find changelog a sensible way to keep track of our changes and I find it helpful to go back in time to see when a certain change was done and what was the state of the repository then to compare with the current version so as to re-assess whether the change done back then makes sense now. > Let me know if I should leave it or clean it up. I prefer that you leave it. > Regarding commit 7020dd5d: > Are the ldflags necessary, since the binary builds fine without them set? > Especially the kitty.VCSRevision option, which is only really used in > --version, > as shown in this upstream commit[9]. I do not find any commit at [9] but rather the lintian output. I simply decided to emulate the way in which upstream buildsystem would behave to avoid surprises so I'd be OK with keeping it that way. LMK if you disagree. > > * Can you please clean up some of the lintian stuff? And then we could > > upload the new release. > > The latest lintian report from the (newly discovered) GitLab Salsa pipeline > can > be found here[9]. > > I can go through and fix most of the issues lintian reports, but I would like > discuss with you the unusual-interpreter warning in the kitty binary package. > All the kitty/**/*.py files are using a `#!/usr/bin/env python` shebang,
Bug#1055650: rebuild fails with node-typescript 4.9.5 in experimental
Package: node-agent-base
Version: 6.0.2+~cs5.4.2-2
Severity: important
User:debian...@lists.debian.org
Usertags: typescript495
Hi,
This package's rebuild failed with node-typescript 4.9.5 currently in
experimental.
node-typescript 4.9.5 is planned to be uploaded to unstable in about two weeks
to
one month time, so please make sure this package will be ready for it. The
severity
of this bug will be raised to serious after node-typescript 4.9.5 is uploaded
to unstable.
Relevant errors;
make[1]: Entering directory '/<>'
tsc
src/index.ts(196,10): error TS2339: Property 'secureEndpoint' does not exist on
type
'never'.
make[1]: *** [debian/rules:7: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:4: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Full build log is attached.
--
PGP: BC55 8A19 E57C 716D D12F 2FA2 EEED 479E 6CEC F707
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on operator
+==+
| node-agent-base 6.0.2+~cs5.4.2-2 (amd64) Mon, 06 Nov 2023 22:02:15 + |
+==+
Package: node-agent-base
Version: 6.0.2+~cs5.4.2-2
Source Version: 6.0.2+~cs5.4.2-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full
I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-84985a51-84ff-4bb8-b69b-8a3ba26ec0a7' with '<>'
Copying /home/weepingclown/debian/js/typescript/node-typescript_4.9.5+ds1-1_all.deb to Sbuild::ChrootSchroot=HASH(0x55a22c5b85e0)->get('Location')...
I: NOTICE: Log filtering will replace 'build/node-agent-base-HcZZsd/resolver-KEOTnU' with '<>'
+--+
| Update chroot|
+--+
Get:1 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ InRelease
Ign:1 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ InRelease
Get:2 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ Release [603 B]
Get:2 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ Release [603 B]
Get:3 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ Release.gpg
Ign:3 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ Release.gpg
Get:4 file:/build/node-agent-base-HcZZsd/resolver-CCZpUT/apt_archive ./ Packages [980 B]
Get:5 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:8 http://deb.debian.org/debian unstable/main Sources T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [218 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Get:9 http://deb.debian.org/debian unstable/main amd64 Packages T-2023-11-06-2008.27-F-2023-11-01-2007.23.pdiff [236 kB]
Fetched 779 kB in 4s (216 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Calculating upgrade...
The following packages will be upgraded:
fakeroot libdb5.3 libfakeroot linux-libc-dev
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2815 kB of archives.
After this operation, 35.8 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 libdb5.3 amd64 5.3.28+dfsg2-3 [697 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 libfakeroot amd64 1.32.2-1 [29.1 kB]
Get:3 http://deb.debian.org/debian unstable/main amd64 fakeroot amd64 1.32.2-1 [73.9 kB]
Get:4 http://deb.debian.org/debian unstable/main amd64 linux-libc-dev amd64 6.5.10-1 [2016 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 2815 kB in 1s (4755 kB/s)
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 11493 files and directories currently installed.)
Preparing to unpack .../libdb5.3_5.3.28+dfsg2-3_amd64.deb ...
Unpacking libdb5.3:amd64 (5.3.28+dfsg2-3) over (5.3.28+dfsg2-2) ...
Setting up libdb5.3:amd64
Bug#1055649: linux: Microphone does not work on ThinPad P14s AMD (Zen4/Phoenix), fixed by enabling 2 SOC DSP modules
Package: linux
Version: 6.5.3-1~bpo12+1
Severity: normal
Tags: patch
The amd64 debian kernels miss the driver for Zen4 ("Phoenix", "Pink
Sardine") Audio Coprocessor/DSP.
So affects microphone support in recent laptops such as the ThinkPad P14s
Gen4 AMD.
Simple fix:
--- .config.old 2023-11-08 18:59:51.375718658 +0100
+++ .config 2023-11-08 19:08:38.271156846 +0100
@@ -6812,7 +6812,8 @@
CONFIG_SND_AMD_ACP_CONFIG=m
# CONFIG_SND_SOC_AMD_ACP_COMMON is not set
# CONFIG_SND_SOC_AMD_RPL_ACP6x is not set
-# CONFIG_SND_SOC_AMD_PS is not set
+CONFIG_SND_SOC_AMD_PS=m
+CONFIG_SND_SOC_AMD_PS_MACH=m
# CONFIG_SND_ATMEL_SOC is not set
# CONFIG_SND_BCM63XX_I2S_WHISTLER is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
-- System Information:
Debian Release: 11.8
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-0.deb11.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
c u
henning
Bug#1042659: closed by Debian FTP Masters (reply to Félix Sipma ) (Bug#1042659: fixed in restic 0.16.0-1)
Hi Andreas, I was working for a long time on a newer release of restic, and finally resolved it by disabling azure. This particular bug was completely out of my radar and I just noticed about it when preparing the upload. Sorry about wasting your time, this was of course not my intention. Regards, On 2023-11-02 06:59+0100, Andreas Metzler wrote: On 2023-11-01 Debian Bug Tracking System wrote: [...] #1042659: restic: FTBFS with Sphinx 7.1, docutils 0.20: TypeError: not all arguments converted during string formatting It has been closed by Debian FTP Masters (reply to Félix Sipma ). [...] * New upstream version 0.16.0 (Closes: #1031235, #1042659) [...] In future could we pretty pretty pretty please have a minimum amount of communication? If you sent something like "I am working on this" or "going to work on this in the next days" to the bug report I would not have wasted time and effort on diagnosing the issue, digging out the patch and preparing and testing a NMU. TIA, cu andreas -- Félix signature.asc Description: PGP signature
Bug#1055648: debian-edu-config: once trixie development started, remove cruft from pre-pkgsel
Package: debian-edu-config
Version: 2.13.x
Severity: wishlist
Dear Maintainer,
the attached patch should be applied once trixie development for Debian Edu has
started.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Cholera is over. It's safe to put sewage in our drinking water again.
(@stimmyskye)
From 7f048da3c15ee93d446bc33a716cf3d7a33a96dd Mon Sep 17 00:00:00 2001
From: Wolfgang Schweer
Date: Tue, 7 Nov 2023 09:51:40 +0100
Subject: [PATCH 2/2] cleanup pre-pkgsel from cruft
---
share/debian-edu-config/d-i/pre-pkgsel | 32 --
1 file changed, 32 deletions(-)
diff --git a/share/debian-edu-config/d-i/pre-pkgsel b/share/debian-edu-config/d-i/pre-pkgsel
index 295b6528..7492687f 100644
--- a/share/debian-edu-config/d-i/pre-pkgsel
+++ b/share/debian-edu-config/d-i/pre-pkgsel
@@ -266,37 +266,6 @@ EOF
fi
}
-create_initial_localadmin_user() {
-LOCAL_USER_ID="localadmin"
-LOCAL_USER_GECOS="Local Administrator"
-LOCAL_USER_UIDNUMBER="1000"
-LOCAL_USER_PRIMGIDNUMBER="1000"
-
-LOCAL_USER_INGROUPS="$LOCAL_USER_INGROUPS adm sudo"
-
-if db_get passwd/root-password-crypted && [ "$RET" ] ; then
- log "No clear text root password, unable to use it for creating the initial local user"
-else
- # retrieve root password
- db_get passwd/root-password
- LOCAL_USER_PASSWD=$RET
- # create initial local user
- in-target /usr/sbin/addgroup --gid $LOCAL_USER_PRIMGIDNUMBER $LOCAL_USER_ID 1>&2 || true
- in-target /usr/sbin/adduser --gid $LOCAL_USER_PRIMGIDNUMBER \
- --firstuid $LOCAL_USER_UIDNUMBER \
- --home /home/$LOCAL_USER_ID \
- --shell /bin/bash \
- --disabled-login \
- --gecos "$LOCAL_USER_GECOS" $LOCAL_USER_ID 1>&2 || true
- # add initial local user to some standard system groups
- for group in ${LOCAL_USER_INGROUPS}; do
- in-target /usr/sbin/adduser $LOCAL_USER_ID $group 1>&2 || true
- done
- # set password (batch mode)
- in-target /bin/sh -c "echo ${LOCAL_USER_ID}:${LOCAL_USER_PASSWD} | /usr/sbin/chpasswd" 1>&2 || true
-fi
-}
-
# Work around grub bug #712907 (see also bug #763580) by preseeding
# grub-installer/choose_device to the disk used by /target/boot
# This fix it for the most common case.
@@ -348,7 +317,6 @@ for p in $(echo $PROFILE | tr , " ") ; do
case $p in
# Only do this for the networked tasks, not for standalone
Main-Server|Workstation|Roaming-Workstation|LTSP-Server|Minimal)
- #create_initial_localadmin_user
in-target /usr/share/debian-edu-config/tools/preseed-ldap-kerberos
in-target /usr/share/debian-edu-config/tools/preseed-sitesummary
--
2.42.0
signature.asc
Description: PGP signature
Bug#1055647: debian-edu-config: On main server internal name resolving fails: /etc/resolv.conf is empty
Package: debian-edu-config Version: 2.12.32 Severity: important Dear Maintainer, Wolfgang Schweer wrote: On a main server, internal name resolving fails: /etc/resolv.conf is empty. Reason is a wrong /etc/network/interfaces file, generated during installation. In case the LTSP-server profile is chosen additionally, this file is rewritten and a correct resolv.conf file is generated. The d-i/pre-pgksel script writes nameserver and search entries concerning the loopback interface. This used to work for more than a decade. After ifupdown package changes, those entries are no longer evaluated; they need to be moved to the eth0 interface to obtain a correct resolv.conf file. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If a monkey hoarded more bananas than it could eat, while most of the other monkeys starved, scientists would study that monkey to figure out what the heck was wrong with it. When humans do it, we put them on the cover of Forbes. signature.asc Description: PGP signature
Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management
Hi Colin,
Colin King (gmail) ezt írta (időpont: 2023.
nov. 7., K, 15:18):
>
> Hi Balint,
>
> Thanks for responding with the review. I was waiting for the upstream
> project to release a 0.4 with some minor fixes before re-uploading to
> mentors.
>
> I've addressed the issues you found as below:
Please see my observations below.
> On 22/10/2023 22:38, Bálint Réczey wrote:
> > Hi Colin,
> >
> > I've checked the second upload at [1].
> > As you can see in the Lintian warnings there is a .git directory which
> > is not ideal for a source package.
> > I suggest using the most widely used git-buildpackage based workflow
> > where the gbp command takes care of exporting the source package
> > without the .git dir from the packaging repository.
> > I'd be happy to set up a packaging repo for you at
> > https://salsa.debian.org/debian/libtypec and add you as a maintainer
> > as described in [2]
I still hold up my offer about setting up a git repo for packaging on
Salsa. That comes with the benefit of automated fixes from Debian
Janitor and I could also comment on changes right where they happened.
> > Other observations regarding the packaging:
> >
> > * There is debian/install and also there are binary package specific
> > *.install files which is slightly confusing.
> > I suggest dropping debian/install.
>
> Fixed
>
> > * In the debian/*.install files you need to specify only the target
> > dir, not the target file.
>
> Fixed
>
> >In libtypec-dev
> > /usr/share/pkgconfig/${DEB_HOST_MULTIARCH}/libtypec.pc/libtypec.pc
> > gets shipped, which is not desired.
>
> Fixed
I think my comment here was misleading, sorry for that.
Shipping *.pc is desired, shipping it in the .../libtypec.pc/ dir as a
result of specifying .../libtypec.pc as the target dir in the .install
file was not desired. It was even patched to have the right content.
Please ship the .pc file in the -dev package.
> > * libtypec.h seems to be the same on all architectures. Does it have
> > to be shipped in a multiarch include location?
>
> Fixed. Now in /usr/include and in the multiarch include location
>
> > * Binary packages in debian/control are not marked as Multi-Arch: same
> > * Please target experimental. The package needs to pass NEW and to
> > migrate to testing it will need a new source-only upload anyway.
> >
>
> Fixed.
>
> Please review the 0.4 release upload and let me know if this can be
> sponsored further to the changes I made.
* Both libtypec-dev.install and libtypec1.install lists
usr/lib/${DEB_HOST_MULTIARCH} and as a result both packages ship the
*.so symlink and *.so.0.4.0.
Please ship *.so.0.4.0 in the library package and the *.so symlink in
the -dev package only.
* As you switched back to use upstream's 0.4.0 SO version the .symbols
file became wrong not matching the shipped SO version. Please fix
that and also switch to the libtypec0 package name since it needs to
match upstream's major SO version.
* I'd recommend asking upstream to switch to semantic SO versioning
instead of using the project's version and switching to major version
1 when the API stabilized.
Cheers,
Balint
> Kind regards,
>
> Colin
>
>
> > Cheers,
> > Balint
> >
> > [1] https://mentors.debian.net/package/libtypec/
> > [2]
> > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> >
> > On Thu, 3 Aug 2023 17:00:58 +0100 "Colin King (gmail)"
> > wrote:
> >> Hi,
> >>
> >> I've uploaded a fixed package that addresses these issues.
> >>
> >> Colin
> >>
> >> On 18/07/2023 08:50, Adam Borowski wrote:
> >>> On Mon, Jul 17, 2023 at 03:29:13PM +0100, Colin King (gmail) wrote:
> * Package name : libtypec
> Version : 0.3-1
> * URL : https://github.com/Rajaram-Regupathy/libtypec
> >>>
> libtypec1 - generic interface for efficient USB-C port management
> libtypec-dev - Development files for an interface for USB-C port
> management
> >>>
> libtypec (0.3-1) unstable; urgency=low
> .
> * Initial release (Closes: #1023477)
> * Add patch 0001-fix-libtypec-so-version.patch to fix .so name
> version
> >>>
> >>> Hi!
> >>> Before doing manual review, let's start with lintian:
> >>>
> >>> E: libtypec1: pkg-config-multi-arch-wrong-dir full text contains
> >>> architecture specific dir x86_64-linux-gnu
> >>> [usr/share/pkgconfig/libtypec.pc]
> >>> W: libtypec-dev: empty-binary-package
> >>> W: libtypec1: lacks-unversioned-link-to-shared-library example:
> >>> usr/lib/x86_64-linux-gnu/libtypec.so
> >>> [usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0]
> >>> W: libtypec1: link-to-shared-library-in-wrong-package
> >>> usr/lib/x86_64-linux-gnu/libtypec.so.0.3.0
> >>> [usr/lib/x86_64-linux-gnu/libtypec.so]
> >>>
> >>>
> >>> Meow!
> >>
> >>
> >>
> >
>
>
Bug#1055646: gdb: extremely slow response to basic commands
Package: gdb Version: 13.1-3 Severity: important X-Debbugs-Cc: tomasz.paw...@wp.eu The gdb compiled for Debian12 is extremely slow - it takes tens of seconds to minutes to execute even the simplest commands, like "info args", or "backtrace" - for a medium size program. I've modified Codeblocks IDE to measure gdb response times, here's the link: https://forums.codeblocks.org/index.php/topic,25561.msg174050.html#msg174050 Apparently the problem is with the build flags used to compile gdb. I've made a test build of the source package: "gdb-source_13.1-3_all.deb" build flags: > export target_configargs="--enable-threading --with-gnu-ld --enable- libbacktrace --with-zstd --with-system-readline --with-system-zlib --with- xxhash=yes --disable-unit-tests --disable-sim" > ./configure --enable-lto --enable-vtable-verify --disable-libstdcxx The newly built gdb is working as expected - measured response times are close to zero (see the link posted above) Regards -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdb depends on: ii libbabeltrace1 1.5.11-1+b2 ii libc6 2.36-9+deb12u3 ii libdebuginfod1 0.188-2.1 ii libexpat1 2.5.0-1 ii libgcc-s1 12.2.0-14 ii libgmp102:6.2.1+dfsg1-1.1 ii libipt2 2.0.5-1 ii liblzma55.4.1-0.2 ii libmpfr64.2.0-1 ii libncursesw66.4-4 ii libpython3.11 3.11.2-6 ii libreadline88.2-1.3 ii libsource-highlight4v5 3.1.9-4.2+b3 ii libstdc++6 12.2.0-14 ii libtinfo6 6.4-4 ii libxxhash0 0.8.1-1 ii libzstd11.5.4+dfsg2-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gdb recommends: ii libc6-dbg [libc-dbg] 2.36-9+deb12u3 Versions of packages gdb suggests: ii gdb-doc13.1-1 pn gdbserver -- no debconf information
Bug#1055228: plplot: FTBFS on armhf (test segfault)
Control: tags -1 + confirmed help
* Gianfranco Costamagna [2023-11-02 15:09]:
Source: plplot
Version: 5.15.0+dfsg2-6
Severity: serious
Hello, I found the package FTBFS on Ubuntu, checked on amdahl and found the
same issue.
/usr/bin/make -f examples/fortran/CMakeFiles/x31f.dir/build.make
examples/fortran/CMakeFiles/x31f.dir/build
make[5]: Entering directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
make[5]: Nothing to be done for 'examples/fortran/CMakeFiles/x31f.dir/build'.
make[5]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
[ 46%] Built target x31f
/usr/bin/make -f examples/CMakeFiles/test_fortran_svg.dir/build.make
examples/CMakeFiles/test_fortran_svg.dir/depend
make[5]: Entering directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /home/locutusofborg/plplot-5.15.0+dfsg2
/home/locutusofborg/plplot-5.15.0+dfsg2/examples
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/CMakeFiles/test_fortran_svg.dir/DependInfo.cmake
"--color="
make[5]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
/usr/bin/make -f examples/CMakeFiles/test_fortran_svg.dir/build.make
examples/CMakeFiles/test_fortran_svg.dir/build
make[5]: Entering directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples &&
/usr/bin/cmake -E echo "Generate fortran results for svg device"
Generate fortran results for svg device
cd /home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples &&
env
EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples
SRC_EXAMPLES_PREFIX=/home/locutusofborg/plplot-5.15.0+dfsg2/examples
OUTPUT_DIR=/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/examples/test_examples_output_dir
/bin/bash
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/plplot-test.sh
--verbose --front-end=fortran --device=svg
Testing front-end fortran
x16af
x00f
x01f
x02f
x03f
x04f
x05f
x06f
x07f
x08f
x09f
/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf/plplot_test/test_fortran.sh: line 54: 3932208 Bus
error $DEBUG_CMD "$fortrandir"/x${index}f -dev $device -o
"${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> fortran_${device}_test.error >|
"${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
Program received signal SIGBUS: Access to an undefined portion of a memory
object.
Backtrace for this error:
make[5]: *** [examples/CMakeFiles/test_fortran_svg.dir/build.make:388:
examples/test_examples_output_dir/x00f01.svg] Error 1
make[5]: *** Deleting file 'examples/test_examples_output_dir/x00f01.svg'
make[5]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
make[4]: *** [CMakeFiles/Makefile2:5049:
examples/CMakeFiles/test_fortran_svg.dir/all] Error 2
make[4]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
make[3]: *** [CMakeFiles/Makefile2:7121:
examples/CMakeFiles/test_noninteractive.dir/rule] Error 2
make[3]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
make[2]: *** [Makefile:2243: test_noninteractive] Error 2
make[2]: Leaving directory
'/home/locutusofborg/plplot-5.15.0+dfsg2/obj-arm-linux-gnueabihf'
make[1]: *** [debian/rules:55: override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/locutusofborg/plplot-5.15.0+dfsg2'
make: *** [debian/rules:48: binary] Error 2
Full log attached
Thanks for this bug report. I can indeed reproduce the problem.
It was triggered by the recent change in dpkg-buildflags, which now
includes -fstack-clash-protection in FFLAGS. This was done through commit
1d46b351f [1], , intended to fix Bug#1054583 [2], and which got included
in version 1.22.1 of dpkg-dev, released on October 30.
The Fortran example x09f.f90, which is exercised during the building of
plplot, now fails on armhf, due to the use of the compiler option
-fstack-clash-protection. I did not check whether this is also the case
for arm64 and armel.
As far as I can tell, this is due to a global variable (tr) that is not
correctly accessed in a private function (mypltr) of the x09f program.
There may be a programming error in x09f.f90 or this may be a problem
with gfortran on armhf. My knowledge of Fortran is almost non existent
and I will need the help of experts, in order to fix the issue.
Best,
Rafael Laboissière
[1] https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=1d46b351f
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054583
Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal
On Thu, 2023-11-09 at 00:32 +0530, Nilesh Patra wrote: > > On the contrary, avoiding the use of dh-golang as done in this repo[3] > > causes > > all the tests to pass without problem, and I'm unsure to why that is. > > This was due to some caveats with the build system and also how > dh_golang works. We added in a patch that'd skip running gen-go-code.py > and this was being used at more than one place. Doesn't the update_go_generated_files function in setup.py[6] run gen-go- code.py, specifically `kitty +launch gen-go-code.py`? Patch#0003[7] adds the `return` statement right afterwards. > I've fixed up the build and the tests and the package seems to > build/work. I suppose we should be pushing it to debian experimental for > now since this introduces some completely new things. Let me know if you > disagree. Not at all! I completely agree with uploading it to experimental (once we get all the issues reported by lintian resolved), since it a large version bump and we've changed a lot of things to get the Golang parts to build. > I've pushed all my changes to the debian/experimental branch on the > existing salsa repo[5] and also added your access to it so you could > push directly. Thanks, especially for adding and pushing my commits! > > We may have to take the approach Fedora has taken, where they've skipped any > > continuously failing tests[4]. > > For now I disabled two tests in the go code that tries to fiddle with > proc/devfs and can potentially fail in a chroot. Python tests probably > also try to do some non-standard stuff and we could disable it later if > it goes flaky on the buildd machines. If we have time, it's probably good to get to the bottom of these flaky tests and patch them instead of skipping them outright. This may involve filing bug reports upstream, and creating PRs when necessary upstream in order to improve their test suites for both Python and Golang. These issues regarding the tests have been brought up before with upstream. For instance, James opened an issue[8] on upstream's GitHub regarding the test_bash_integration test failing on unstable. > That said, I want to discuss/ask a few things: > * Can you take a look at my commits and let me know if you have any > comments? Regarding commit 38ea7407: This is a nitpick (and I think this is a mistake): should the patch file end with .patch instead of .py? It would probably be beneficial if we could setup the gbp workflow by hand, ensuring the upstream branch is up to date and setting up a patch- queue/debian/(unstable|experimental) branch. Regarding commit d847dbfe: The d/ch entry needs some cleaning up, with the merging and removal of some points. (I'm assuming you used `gbp dch`.) For example, > * patch: make setup.py compatible with GOPATH mode is probably not something the end user needs to know about. Let me know if I should leave it or clean it up. Regarding commit 7020dd5d: Are the ldflags necessary, since the binary builds fine without them set? Especially the kitty.VCSRevision option, which is only really used in --version, as shown in this upstream commit[9]. > * Can you please clean up some of the lintian stuff? And then we could > upload the new release. The latest lintian report from the (newly discovered) GitLab Salsa pipeline can be found here[9]. I can go through and fix most of the issues lintian reports, but I would like discuss with you the unusual-interpreter warning in the kitty binary package. All the kitty/**/*.py files are using a `#!/usr/bin/env python` shebang, whereas lintian wants `#!/usr/bin/env python3`. Should we add a simple recursive find and replace to debian/rules? WDYT? > * Since we both are interested in kitty's packaging, I think we have two > options: > - Either you or me would be in the "Maintainer" field and the other one > would > be in "Uploader" field. > - Add ki...@packages.debian.org as the maintainer and add both of us > as uploaders (that means we subscribe to the package email > ofcourse). > Which one do you think we should do? I don't really have a preference, so I'm happy with whatever you would like to do regarding that. Keep in mind that the contact in the Maintainer field will pretty much be the "face" of the package. > * I suppose the maintenance of this package will keep getting messy due > to upstream mixing up two language build systems in a fairly non-standard > way. > I suppose it makes sense to ask upstream if they'd consider to switch > to something that eases maintenance burden on us (Debian). WDYT? I think that's a good idea, but if we do ask upstream, we should propose a solution to them to make it as easy as possible for them to implement, and perhaps some work on our side. Perhaps splitting up the kitty and kittens components into separate folders/repos? Or make it so that these components can build independently of each other (setup.py builds kitty only, `go build` builds kittens only)? > > [1]:
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
Package: orphan-sysvinit-scripts Version: 0.15 Severity: wishlist Dear Maintainer, the mdadm maintainer has dropped the initscript without warning: mdadm (4.2+20230227-1) experimental; urgency=medium * Removing sysvinit scripts in favour of systemd units: - properly checkrestart mdmonitor (Closes: #815834). - no update-rc.d warnings anymore (Closes: #822354). - properly shutdown (Closes: #829621). - making /etc/default/mdadm obsolete for most things (Closes: #850180). * Removing cron jobs in favour of systemd timers: - daily checks also work if system is not always on (Closes: #889978). Even the cronjob is gone. Can you please take over the missing files? Many greetings, Stephan -- System Information: Debian Release: trixie/sid APT prefers oldstable-updates APT policy: (900, 'oldstable-updates'), (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.1 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages orphan-sysvinit-scripts depends on: ii ucf 3.0043+nmu1 orphan-sysvinit-scripts recommends no packages. orphan-sysvinit-scripts suggests no packages. -- no debconf information -- |If your life was a horse, you'd have to shoot it.|
Bug#1004125: Screen flickering with 2.4.109
Control: tag -1 -moreinfo On Thursday, 9 November 2023 08:48:27 CET Philipp Marek wrote: > > If you can still reproduce this with the latest kernel and libdrm > > packages, > > can you open a new issue upstream? And mention that in this bug? > > Well, right now with 6.5.0-1-amd64 I can't reproduce. > (Yeah, that's not the latest, I know) That sounds like you expect the issue to return 'any moment', so I'll refrain from closing this bug. From https://bugs.debian.org/796087 it appears that you're not the only one who sees issues come and go periodically. The goal was to test it with a newer kernel/libdrm versions, so testing with 6.5.0-1 was good enough AFAIC. If -4 would reintroduce the problem, that would be an interesting data point. Looking at libdrm's commit log, I see periodically commits where they sync up with the upstream linux kernel. Maybe these issues come and go when there is/ was a mismatch between the kernel and libdrm (which the sync up then fixes)? At https://snapshot.debian.org/binary/libdrm-intel1/ you can find (most) previous versions and if you still have the 5.15.0-3 kernel installed, could you try if version 2.4.110-1 with it would also solve the problem? And try newer libdrm-intel1 versions if not till you find one where it is fixed. signature.asc Description: This is a digitally signed message part.
Bug#1055487: nmu: openstructure_2.6.0~rc-1~exp spglib_2.1.0-1~exp
Hi, On 2023-11-09 15:57, Sebastian Ramacher wrote: We can of course schedule the binNMUs, but I am wondering why are those required? I wanted to check whether they rebuild successfully on buildd. I have not done this before, just wanted to be extra careful this time. But of course I may as well proceed with transitions without the binNMUs. Best, Andrius
Bug#1055644: linux: amd driver not loaded since 6.4.x
Source: linux Severity: important I am using an AMD R5 3600X CPU with an AMD RX6650XT GPU. My DE setup is Plasma wayland plus sddm, and the latter have been unable to start ever since the first version of Debian Linux kernel 6.4.4-1. Ever time I boot with newer kernel it just stop at the systemd log of sddm and SimpleMonitor. I have tried installing linux 6.6 rc from Ubuntu, updating firmwares from mainline or Arch Linux, switching the DisplayPort cable to HDMI, switching to greetd(which said 0 gpu), tweaking and resetting sddm (and kscreen) config, but nothing works. Switching to lxdm + lxqt did yeild some positive result. I ended up in Plasma X11 with unknown monitor, no HDMI audio output and a fixed 93Hz display setting while my monitor is 2650*1440 165Hz. Here's what I found at Xorg.0.log: [32.288] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [32.288] (II) FBDEV: driver for framebuffer: fbdev [32.288] (II) VESA: driver for VESA chipsets: vesa [32.288] (EE) open /dev/dri/card0: No such file or directory [32.288] (WW) Falling back to old probe method for modesetting [32.288] (EE) open /dev/dri/card0: No such file or directory [32.288] (II) Loading sub module "fbdevhw" [32.288] (II) LoadModule: "fbdevhw" [32.288] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [32.288] (II) Module fbdevhw: vendor="X.Org Foundation" [32.288]compiled for 1.21.1.9, module version = 0.0.2 [32.288]ABI class: X.Org Video Driver, version 25.2 [32.288] (EE) Unable to find a valid framebuffer device [32.288] (WW) Falling back to old probe method for fbdev [32.288] (II) Loading sub module "fbdevhw" [32.288] (II) LoadModule: "fbdevhw" [32.288] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [32.288] (II) Module fbdevhw: vendor="X.Org Foundation" [32.288]compiled for 1.21.1.9, module version = 0.0.2 [32.288]ABI class: X.Org Video Driver, version 25.2 [32.288] (II) FBDEV(2): using default device [32.288] vesa: Refusing to run, Framebuffer or dri device present [32.288] (EE) Screen 0 deleted because of no matching config section. [32.288] (II) UnloadModule: "modesetting" [32.288] (EE) Screen 0 deleted because of no matching config section. [32.288] (II) UnloadModule: "fbdev" [32.288] (II) UnloadSubModule: "fbdevhw" And here is the sddm systemd log: 11月 09 16:39:37 debian systemd[1]: Starting sddm.service - LSB: Start SDDM... 11月 09 16:39:37 debian systemd[1]: Started sddm.service - LSB: Start SDDM. 11月 09 16:41:10 debian systemd[1]: sddm.service: Deactivated successfully. 11月 09 16:41:10 debian systemd[1]: Stopped sddm.service - Simple Desktop Display Manager. I will provide more debug info if needed. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017577: sqlcipher: new upstream version available
Salsa is updated with version 4.5.5, and an upload heading for experimental was just submitted for NEW processing due to the SONAME change. I forgot to close this issue, and suggest it is closed when the upload to unstable happen. -- Happy hacking Petter Reinholdtsen
Bug#1055636: ogre: Add loongarch64 support
Control: reassign -1 src:ogre-1.12 The newer branch ogre-1.12 seems to have the same issue. ogre-1.9 was not included in bookworm and is not going to be included in trixie, so I'm reassigning this to ogre-1.12 rather than cloning it. Please consider this to be "won't fix" for ogre-1.9. On Thu, 09 Nov 2023 at 11:54:29 +, JiaLing Zhang wrote: > /* Find the arch type */ > -#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) || > defined(__alpha__) || defined(__ia64__) || defined(__s390__) || > defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) || > defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen > == 64)) > +#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) || > defined(__alpha__) || defined(__ia64__) || defined(__s390__) || > defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) || > defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen > == 64)) || defined(__loongarch64) > # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 > #else > # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 If this is as a Debian-specific patch, gcc already gives us this information: #if __SIZEOF_POINTER__ == 8 #define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 #elif __SIZEOF_POINTER__ == 4 #define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 #else #error Architecture word size not detected or not supported #endif (That assumes gcc or clang, and will not work with non-gcc-compatible compilers like MSVC, but Debian doesn't support such compilers.) Upstream, I think this would be better done by detecting sizeof(void *) at build time using CMAKE_SIZEOF_VOID_P, and substituting it into CMake/Templates/OgreBuildSettings.h.in, perhaps something like this: #define OGRE_CONFIG_SIZEOF_POINTER @CMAKE_SIZEOF_VOID_P@ and then making use of that in OgrePlatform.h: #if OGRE_CONFIG_SIZEOF_POINTER == 8 #define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 #elif OGRE_CONFIG_SIZEOF_POINTER == 4 #define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 #else #error Architecture word size not detected or not supported #endif That way, there would be no need to keep updating this list with every new CPU architecture that is invented. smcv
Bug#1055643: mutter 45.1 not installable from experimental
Package: mutter Version: 45.1-1 Severity: normal Dear Maintainer, * What led up to the situation? sudo apt install mutter -t experimental Die folgenden Pakete haben unerfüllte Abhängigkeiten: mutter : Hängt ab von: mutter-common (>= 45.1-1) aber 45.0-3 soll installiert werden E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete. * What exactly did you do (or not do) that was effective (or ineffective)? cannot do anything about it * What was the outcome of this action? NA * What outcome did you expect instead? mutter-common 45.1 seems to be missing in experimental -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mutter depends on: ii adwaita-icon-theme45.0-1 ii gnome-settings-daemon-common 45.0-1 ii gsettings-desktop-schemas 45.0-1 ii libc6 2.37-12 ii libgles2 1.7.0-1 ii libglib2.0-0 2.78.1-2 ii libmutter-13-045.0-3 ii libwayland-client01.22.0-2.1 ii mutter-common 45.0-3 ii zenity3.44.2-1 mutter recommends no packages. Versions of packages mutter suggests: ii gnome-control-center 1:45.1-1 ii xdg-user-dirs 0.18-1 -- no debconf information
Bug#1055194: transition: openturns
Control: tags -1 confirmed On 2023-11-01 22:49:33 +0100, Pierre Gruet wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: opentu...@packages.debian.org > Control: affects -1 + src:openturns > > Dear Release Team, > > I would like to request a transition slot for openturns. It has been accepted > to experimental after a SONAME bump as some symbols changed in a not > backward-compatible way. It builds correctly. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1054657: transition: r-bioc-biocgenerics
Le Thu, Nov 09, 2023 at 02:01:57PM +0100, Paul Gevers a écrit : > > The first and foremost reason why we're not enthusiastic about defaulting to > removal of packages from testing is that that's a disservice to our users of > testing. Hi Paul, I understand that you feel responsible for the state of testing, but please consider that the r-bioc-* package users are our users too. Some of them are our colleagues, or our friends. Those who we do not know, we see their blogs, their toots, their Dockerfiles. We meet them at conferences. We also feel responsible and we have the intuition that having the packages absent from testing for a couple of weeks is not going to cause too much trouble. > I have the *feeling* (which might be unjust, but then consider past > interactions) that we often need to tell you about issues and how to solve > them. A lot of the issues are due to continuous integrations tests, where we uncover bugs on architectures unsupported upstream (who only builds on amd64 and Apple arm64). One of the reasons we sometimes take time to make a visible action in response to CI failures is that we, like you, are limited in our time. But if this is important for you we can surely write ack messages faster. > If the r-bioc team were to actively monitor the situation I read the R and Bioc devel mailing list. I am upstream developer of a Bioconductor package. Yes, I have been caught by surprise in the last transition by the addition of new packages at the core of the dependency tree. Yes, reputation is easy to lose and hard to gain. If I tell you that I have been more careful because I wanted to avoid it to happen again, you are free to think that the previous mistake proves my incompetence, and that it means that my care and monitoring are useless. This is what I feel when I see the new request from your team coming at the last minute and not as a debriefing of the previous transition. > Several other ecosystems, e.g. perl, python and ruby, do preparation outside > of the Debian archive and often have some idea (or know quite well) of what > to expect during the transition. It's that pro-activeness that makes a > difference to us; it *sounds* much better than "let's start and find out how > much work it is". Maybe it's just the tone, but we're all humans. Please trust us this time, and if you think that next time you need to monitor our monitoring, I can for instance toot regularly under a pre-decided hashtag about our preparation and you can review it at the time of the transition, (in about 5 months; the clock is ticking). Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Bug#1055487: nmu: openstructure_2.6.0~rc-1~exp spglib_2.1.0-1~exp
Control: tags -1 moreinfo Hi Andrius On 2023-11-07 11:15:44 +0200, Andrius Merkys wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hello, > > I want to request binNMU on amd64 for packages recently accepted to > experimental. > > nmu openstructure_2.6.0~rc-1~exp . amd64 . experimental . -m "Rebuild on > buildd" > nmu spglib_2.1.0-1~exp . amd64 . experimental . -m "Rebuild on buildd" We can of course schedule the binNMUs, but I am wondering why are those required? Cheers -- Sebastian Ramacher
Bug#1055642: override: unittest2:oldlibs/optional
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: override X-Debbugs-Cc: unitte...@packages.debian.org, z...@debian.org Control: affects -1 + src:unittest2 Dear FTP Maintainers, Please tag "unittest2" as oldlibs. Alike to enum34, it was a backport of some Python3 novelty to Python2 and is now dead upstream. Packages still using this should be move someday to using plain standard Python3 functionality. Greetings, Alexandre Detiste PS: I do also need this tag to help with python3-six triaging: https://wiki.debian.org/Python3-six-removal
Bug#1055637: Debian debdiff attached
For your convenience, i've attached the Debian debdiff - the original patch
contained some binaries as part of the unit test, i removed them and i kept only
the code section.
Let me know.
--
bye,
p.
diff -Nru libabigail-2.4/debian/changelog libabigail-2.4/debian/changelog
--- libabigail-2.4/debian/changelog 2023-10-31 11:03:41.0 +
+++ libabigail-2.4/debian/changelog 2023-11-09 11:29:34.0 +
@@ -1,3 +1,10 @@
+libabigail (2.4-2) unstable; urgency=medium
+
+ *
debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch:
+- Fix assert violation while setting translation unit for unique types
(Closes: #1055637)
+
+ -- Paolo Pisati Thu, 09 Nov 2023 11:29:34 +
+
libabigail (2.4-1) unstable; urgency=medium
* New upstream version.
diff -Nru
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
---
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
1970-01-01 00:00:00.0 +
+++
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
2023-11-09 11:29:34.0 +
@@ -0,0 +1,100 @@
+From 35eed7922edf2e49604ff9d60eba20357152e36c Mon Sep 17 00:00:00 2001
+From: Dodji Seketeli
+Date: Wed, 8 Nov 2023 14:46:04 +0100
+Subject: [PATCH] Bug 31045 - Don't try setting translation unit for unique
+ types
+
+Unique types (void, pointer to void and variadic parameter types)
+should not have their translation unit set whenever they are being
+added to a scope. This is because they are supposed to be created
+independently from any translation unit, even if technically, they are
+set to the translation unit they are referenced from, for the first
+time.
+
+To handle this, a new function maybe_set_translation_unit is created
+to handle the setting of the translation unit for decls added to a
+scope by scope_decl::{add,insert}_member_decl. That new function
+asserts that unique types should have their translation unit be set.
+
+ * src/abg-ir.cc (maybe_set_translation_unit): Define new static
+ function.
+ (scope_decl::{add,insert}_member_decl): Use it.
+ *
tests/data/test-abidiff-exit/PR31045/zfs-abigail-2.4/libnvpair.{abi,so,suppr}:
+ New test input files.
+ *
tests/data/test-abidiff-exit/PR31045/zfs-abigail-2.4/test-PR31045-report-1.txt:
+ New reference test output.
+ * tests/data/Makefile.am: Add the new test material above to
+ source distribution.
+ * tests/test-abidiff-exit.cc (in_out_specs): Add the input above
+ to this test harness.
+
+Signed-off-by: Dodji Seketeli
+---
+ src/abg-ir.cc | 42 +-
+ 1 file changed, 30 insertions(+), 12 deletions(-)
+
+--- a/src/abg-ir.cc
b/src/abg-ir.cc
+@@ -7974,6 +7974,34 @@
+ && get_canonical_types().empty());
+ }
+
++/// Set the translation unit of a decl
++///
++/// It also perform some IR integrity checks.
++///
++/// This is a sub-routine of scope_decl::{insert,add}_member_decl.
++///
++/// @param decl the decl to set the translation unit for.
++///
++/// @param tu the translation unit to set.
++static void
++maybe_set_translation_unit(const decl_base_sptr& decl,
++ translation_unit* tu)
++{
++ if (translation_unit* existing_tu = decl->get_translation_unit())
++// The decl already belongs to a translation unit.
++// Either:
++//
++// 1/ it's a unique type, in which case we should not add it to
++// any translation unique since unique types are "logically"
++// supposed to belong to no translation unit in particular, as
++// they are unique.
++//
++// 2/ or the decl was already added to this translation unit.
++ABG_ASSERT(tu == existing_tu || is_unique_type(is_type(decl)));
++ else
++decl->set_translation_unit(tu);
++}
++
+ /// Add a member decl to this scope. Note that user code should not
+ /// use this, but rather use add_decl_to_scope.
+ ///
+@@ -7999,12 +8027,7 @@
+ update_qualified_name(member);
+
+ if (translation_unit* tu = get_translation_unit())
+-{
+- if (translation_unit* existing_tu = member->get_translation_unit())
+- ABG_ASSERT(tu == existing_tu);
+- else
+- member->set_translation_unit(tu);
+-}
++maybe_set_translation_unit(member, tu);
+
+ maybe_update_types_lookup_map(member);
+
+@@ -8141,12 +8164,7 @@
+ update_qualified_name(member);
+
+ if (translation_unit* tu = get_translation_unit())
+-{
+- if (translation_unit* existing_tu = member->get_translation_unit())
+- ABG_ASSERT(tu == existing_tu);
+- else
+- member->set_translation_unit(tu);
+-}
++maybe_set_translation_unit(member, tu);
+
+ maybe_update_types_lookup_map(member);
+
diff -Nru libabigail-2.4/debian/patches/series
Bug#1055111: marked as pending in ffmpeg
On Thursday, 9 November 2023 14:14:23 CET Sebastian Ramacher wrote: > > FTR: Upstream has an alternative patch for this (and references this bug): > > https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f01fdedb69e4accb1d1555106d > > 8f682ff1f1ddc7 > I am awayre, yes. But a release of 6.1 is expected soon which hopefully > includes the patch. Ok, excellent :-) I was/am a bit confused about how upstream does releases and when I saw the release/6.1 branch and commits titled "Bump versions prior to 6.1" and "doc/ APIchanges: Add 6.1 cut point" and "version " added to Changelog, I thought the release already happened. But it didn't include that patch. Not seeing the tags attached to commits in master or the release branches added to my confusion. I was planning to look further into this to hopefully understand how they work. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1055641: src:nextpnr: fails to migrate to testing for too long: triggers autopkgtest failures
Source: nextpnr Version: 0.6-1 Severity: serious Control: close -1 0.6-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:nextpnr has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable triggers failures in fpga-icestorm as well as its own autopkgtest fails (the latter one due to what I see as a bug in autopkgtest, but that's trivial to work around on the package side). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=nextpnr OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055640: src:prometheus: fails to migrate to testing for too long: FTBFS on mips64el
Source: prometheus Version: 2.45.0+ds-3 Severity: serious Control: close -1 2.45.1+ds-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:prometheus has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on mips64el. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=prometheus OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055639: surf: flaky autopkgtest: Too few characters detected (0)
Source: surf Version: 2.1+git20221016-5 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails (in this case because it's blocking migration of src:autopkgtest), mostly on armhf and a bit on ppc64el and s390x. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul PS: why does it even use text from a different and very unrelated package? If there's not enough text in it's own source, couldn't it use something that's installed on all Debian systems, such that it doesn't need to be installed additionally and trigger migration runs? https://ci.debian.net/data/autopkgtest/testing/s390x/s/surf/39724716/log.gz 655s autopkgtest [12:16:40]: test command3: timeout -v 5m xvfb-run debian/tests/test_text.sh 655s autopkgtest [12:16:40]: test command3: [--- 657s 657s (surf:7172): dbind-WARNING **: 12:16:42.983: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files 658s Could not determine the accessibility bus address 662s Too few characters detected (0) 662s autopkgtest [12:16:47]: test command3: ---] OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1041838: Bug#1041834: libclang-rt-16-dev: undeclared file conflict with libclang-rt-16-dev-wasm{32,64} on /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm*.a
Control: retitle -1 libclang-rt-17-dev: undeclared file conflict with
libclang-rt-17-dev-wasm{32,64} on
/usr/lib/llvm-17/lib/clang/17/lib/wasi/libclang_rt.builtins-wasm*.a
Sending to the right bug ("bts show --mbox 1041838" was giving the
1041834@b.d.o e-mail address instead of 1041838@b.d.o, so that I was
confused).
On 2023-11-09 14:13:37 +0100, Vincent Lefevre wrote:
> On 2023-07-24 06:54:27 +0200, Helmut Grohne wrote:
> > Control: clone -1 -2
> > Control: reassign -2 libclang-rt-17-dev
> >
> > On Mon, Jul 24, 2023 at 06:45:00AM +0200, Helmut Grohne wrote:
> > > libclang-rt-16-dev installs
> > > /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm{32,64}.a,
> > > which are also installed by libclang-rt-16-dev-wasm{32,64} respectively.
> > > Trying to coinstall these packages in unstable results in an unpack
> > > error. I guess that these files should only be contained in the
> > > respective wasm packages. Don't forget to include the necessary
> > > Breaks+Replaces when fixing this.
> >
> > The same issue exists for version 17.
>
> This should have been retitled. Doing it now.
>
> But looking at
>
> https://packages.debian.org/sid/amd64/libclang-rt-17-dev/filelist
>
> I can't see files with "wasm" in the file names.
>
> If I understand correctly, the fix was done in branch 17 too:
>
>
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/f667185dabd4ebb8fd8bdceed64432a6fff10d37
--
Vincent Lefèvre - Web:
Bug#1055111: marked as pending in ffmpeg
On 2023-11-09 12:35:49 +0100, Diederik de Haas wrote: > On 31 Oct 2023 23:15:11 + Sebastian Ramacher > wrote: > > https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/ > > 5a5de39526bd8ff5f3881cc611968062e076d9fe > > > > > > Workaround build issues with texinfo 7.1 > > > > Closes: #1055111 > > > > FTR: Upstream has an alternative patch for this (and references this bug): > https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f01fdedb69e4accb1d1555106d8f682ff1f1ddc7 I am awayre, yes. But a release of 6.1 is expected soon which hopefully includes the patch. Cheers -- Sebastian Ramacher
Bug#1054657: transition: r-bioc-biocgenerics
Hi Andreas, On 07-11-2023 18:01, Andreas Tille wrote: You did not yet answered the question I asked twice whether we can find a compromise by simply removing packages with missing new dependencies from testing. I consider this a compromise which I would really love to discuss honestly. I'll try to give at least one answer to this question and also add some other remarks after that. The first and foremost reason why we're not enthusiastic about defaulting to removal of packages from testing is that that's a disservice to our users of testing. Yes, we (auto)remove packages from testing, but we mostly do that to remove RC buggy packages that aren't fixed in time. Removal out of the blue is rare. For the current transition, if we remove packages from testing because they are not ready and the transition migrates, these removed packages will suddenly cause systems where any of these packages is installed to hold back a lot of related packages and the user will have to figure out which one is causing the situation, why and how to solve it for their personal situation. (Were we to remove packages in other situations, still installed packages may suddenly fail to run without a proper bug report explaining the situation. In this case that's prevented by the r-api-bioc relation.) Apart from the reasons already mentioned by Sebastian, another reason why at least I am not looking forward to an r-bioc-biocgenerics transition is that I have the *feeling* (which might be unjust, but then consider past interactions) that we often need to tell you about issues and how to solve them. If the r-bioc team were to actively monitor the situation and respond to failures and other problems (you might be already doing this, it might just be a visibility problem) then it would be easier on us even if a transition last a bit. As Sebastian said, for most other transitions the period that requires quite some attention from us is shorter, which means less pushing and popping from stack, and thus a lower mental load. We're doing quite a lot of transitions, longer lasting ones are never nice. Several other ecosystems, e.g. perl, python and ruby, do preparation outside of the Debian archive and often have some idea (or know quite well) of what to expect during the transition. It's that pro-activeness that makes a difference to us; it *sounds* much better than "let's start and find out how much work it is". Maybe it's just the tone, but we're all humans. I realize that the current tools and way of working in the r-bioc ecosystem isn't yet geared towards our ideal mode of operation. If you could try and work towards that, that would be appreciated. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055537: colcon: Does not install under bin/
Hi, I just built a new .deb from source without debian/patches/0001-Respect-DEB_PYTHON_INSTALL_LAYOUT.patch It seems it works as I expected. Best, -- yashi
Bug#1055638: src:haskell-hsyaml-aeson: fails to migrate to testing for too long: FTBFS everywhere
Source: haskell-hsyaml-aeson Version: 0.2.0.1-1 Severity: serious Control: close -1 0.2.0.1-2 Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 1054961 Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:haskell-hsyaml-aeson has been trying to migrate for 61 days [2]. Hence, I am filing this bug. The version in unstable failed to build from source as reported in 1054961. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=haskell-hsyaml-aeson OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1042521: polymake: FTBFS with Perl 5.38: ‘Perl_ck_fun’ was not declared in this scope
Dear David,
On 08/11/2023 23.09, David Bremner wrote:
David Bremner writes:
I didn't have a chance to investigate so far, but I am seeing a test
failure with Polymake 4.11 building with Perl 5.36. I will try to build
with 5.38 and report a proper build log.
*** Failed tests ***
/<>/apps/polytope/rules/slack_ideal.rules:29: testcase 1
expected: regular return
got: EXCEPTION: no more rules available to compute 'GENERATORS
That looks like the same as #1052830.
I was able to reproduce this and it comes from a changed return type of
the Singular saturation command. The attached patch should fix this and
work with both old and new Singular versions.
Best,
Benjamin
commit 4ce0549f510d246c8f69c85c509fc2d13d882442
Author: Benjamin Lorenz
Date: Thu Nov 9 11:15:06 2023 +0100
singular: support new return types for saturation command
This was changed from (ideal, exponent) to just the ideal in singular 4-3-2p5.
To allow older versions we keep using sat but support both return types
instead of switching to the new sat_with_exp.
diff --git a/bundled/singular/apps/ideal/src/singularIdeal.cc b/bundled/singular/apps/ideal/src/singularIdeal.cc
index 4cbc00a6f4..bdade5c29d 100644
--- a/bundled/singular/apps/ideal/src/singularIdeal.cc
+++ b/bundled/singular/apps/ideal/src/singularIdeal.cc
@@ -236,22 +236,24 @@ public:
arg.next->data=(void *)idCopy(J);
// call primdecSY
BOOLEAN res=iiMake_proc(sathdl, nullptr ,);
- if(!res && (iiRETURNEXPR.Typ() == LIST_CMD)){
- lists L = (lists)iiRETURNEXPR.Data();
- SingularIdeal_wrap* result;
- if(L->m[0].Typ() == IDEAL_CMD){
-result = new SingularIdeal_impl((::ideal) (L->m[0].Data()),singRing);
- } else {
-throw std::runtime_error("Something went wrong for the primary decomposition");
+ if(!res) {
+ ::ideal iddata = nullptr;
+ if (iiRETURNEXPR.Typ() == LIST_CMD) {
+lists L = (lists)iiRETURNEXPR.Data();
+if(L->m[0].Typ() == IDEAL_CMD)
+ iddata = (::ideal) L->m[0].Data();
+ } else if (iiRETURNEXPR.Typ() == IDEAL_CMD) {
+iddata = (::ideal) iiRETURNEXPR.Data();
+ }
+ if (iddata != nullptr) {
+SingularIdeal_wrap* result = new SingularIdeal_impl(iddata, singRing);
+iiRETURNEXPR.CleanUp();
+iiRETURNEXPR.Init();
+return result;
}
- iiRETURNEXPR.CleanUp();
- iiRETURNEXPR.Init();
- return result;
- } else {
- iiRETURNEXPR.Init();
- throw std::runtime_error("Something went wrong for the saturation");
}
-
+ iiRETURNEXPR.Init();
+ throw std::runtime_error("saturation: unable to parse ideal from return value");
}
Array primary_decomposition() const
Bug#1055637: libabigail-2.4: assert violation while setting translation unit for unique types
Source: libabigail Version: 2.4-1 Severity: normal Dear Maintainer, while building the zfs-dkms package in Ubuntu/noble, in the checkabi target, abidiff core dumps: https://launchpadlibrarian.net/696568269/buildlog_ubuntu-noble-amd64.zfs-linux_2.2.0-0ubuntu2_BUILDING.txt.gz abigail-2.3 was fine, and it started crashing after we moved to abigail-2.4. I was able to reproduce the issue locally with abigail src from git: $ abidiff --no-unreferenced-symbols --headers-dir1 include --suppressions ./lib/libnvpair/libnvpair.suppr ./lib/libnvpair/libnvpair.abi .libs/libnvpair.so abidiff: ../../src/abg-ir.cc:8004: virtual abigail::ir::decl_base_sptr abigail::ir::scope_decl::add_member_decl(const abigail::ir::decl_base_sptr&): Assertion `__abg_cond__' failed. Aborted (core dumped) and i bisected it down to this commit: commit d00a2cc2da9b33be5a6e5376cbee4591c042d3a3 (break5) Author: Dodji Seketeli Date: Thu May 25 14:15:56 2023 +0200 Bug 30466 - harfbuzz fails self-check on f38 Sent the report upstream, and got a fix: https://sourceware.org/bugzilla/show_bug.cgi?id=31045 Tested the fix against zfs-dkms, it built successfully this time. Can you apply it and cut a new release?
Bug#1054849: haskell-clash-prelude: FTBFS: make: *** [/usr/share/cdbs/1/class/hlibrary.mk:158: build-ghc-stamp] Error 25
tags 1054849 + bookworm thanks I'm adding this tag because I see Adrian has just added version in bookworm using "found". The package indeed FTBFS in bookworm in reproducible-builds: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/arm64/haskell-clash-prelude.html However, I rebuilt the whole of bookworm a week ago, using AWS machines with 2 CPUs, and this package did not fail for me (see attach). No idea why this happens. If this is a Makefile bug, you might want to "amplify" the probability of failure by using make 4.4.x: https://trofi.github.io/posts/238-new-make-shuffle-mode.html Thanks. haskell-clash-prelude_1.6.4-1_amd64-20231102T201250.732Z.gz Description: application/gzip
Bug#1055636: ogre: Add loongarch64 support
Package: ogre-1.9
Severity: serious
File: ogre
Tags: upstream patch ftbfs loong64
Justification: fails to build from source
X-Debbugs-Cc: zhangjial...@loongson.cn
Dear Maintainer,
This package need support for loongarch64,Please help.
--- ogre-1.9-1.9.0+dfsg1.orig/OgreMain/include/OgrePlatform.h
+++ ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgrePlatform.h
@@ -166,7 +166,7 @@ namespace Ogre {
#endif
/* Find the arch type */
-#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) ||
defined(__alpha__) || defined(__ia64__) || defined(__s390__) ||
defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) ||
defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen
== 64))
+#if defined(__x86_64__) || defined(_M_X64) || defined(__powerpc64__) ||
defined(__alpha__) || defined(__ia64__) || defined(__s390__) ||
defined(__s390x__) || defined(__arm64__) || defined(__aarch64__) ||
defined(__mips64) || defined(__mips64_) || (defined(__riscv) && (__riscv_xlen
== 64)) || defined(__loongarch64)
# define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64
#else
# define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32
Bug#1055111: marked as pending in ffmpeg
On 31 Oct 2023 23:15:11 + Sebastian Ramacher wrote: > https://salsa.debian.org/multimedia-team/ffmpeg/-/commit/ > 5a5de39526bd8ff5f3881cc611968062e076d9fe > > > Workaround build issues with texinfo 7.1 > > Closes: #1055111 > FTR: Upstream has an alternative patch for this (and references this bug): https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f01fdedb69e4accb1d1555106d8f682ff1f1ddc7 Salsa's CI (still) succeeds if I replace the custom patch with upstream's. signature.asc Description: This is a digitally signed message part.
Bug#1055505: closed by Debian FTP Masters (reply to Andreas Tille ) (Bug#1055505: fixed in python-pysam 0.22.0+ds-1)
Control: tags -1 upstream Control: forwarded -1 https://github.com/pysam-developers/pysam/issues/1242
Bug#1017577: sqlcipher: new upstream version available
[Petter Reinholdtsen] > I have too little experience with maintaining a shared library to feel > comfortable to do this without further research. Perhaps you can > help? This is still the case. > Perhaps it should go to experimental, or is it better to just move > directly to 4.5.5? Note, several of the patches did not apply in > 4.5.5, so that will require some investigation too. I decided to give this a go, and is almost ready to push migration to version 4.5.5 to salsa. It will happen this evening. I believe it is best to move directly to 4.5.5, change the SONAME and upload to experimental. Uploading to unstable might need some coordination with the reverse build dependencies. Sadly upstream do not so far care about SONAME and backwards compatibility, so we will have to pick SONAME on our own. -- Happy hacking Petter Reinholdtsen
Bug#1053511: [pkg-apparmor] Bug#1053511: Problem found
Hi, Debian (2023-11-08): > Am 08.11.23 um 18:14 schrieb Thorsten Alteholz: >> >> But this looks rather like a local problem. If your /var/*/cups is not >> at the default location, you should adapt your apparmor files on your >> own, shouldn't you? > Oh yes - that's true. Embarrassing ... I'm glad you found the root cause. FWIW, bind-mounts are easier to use with AppArmor than symlinks, for this kind of problems :)
Bug#1040750: please add loong64 arch support in lintian
Dear maintianers, The loong64 support bus been merged , chould you give a new lintian package to sid. [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/484 Thanks, JIaLing
