Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory
found 1069842 4.4.0-1 affects 1069842 + src:rjava thanks Thanks for the quick reply! [ I'm adding the affects so that the bug is shown on the web page for src:rjava. This helps to avoid duplicates, as there are more people reporting FTBFS bugs ] Thanks.
Bug#1069841: python-icalendar: FTBFS: pytz.exceptions.UnknownTimeZoneError: 'America/Godthab'
Package: src:python-icalendar Version: 5.0.11-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild dh_auto_build -O--buildsystem=pybuild I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" module I: pybuild base:311: python3.12 -m build --skip-dependency-check --no-isolation --wheel --outdir /<>/.pybuild/cpython3_3.12_icalendar * Building wheel... running bdist_wheel running build running build_py creating build creating build/lib creating build/lib/icalendar copying src/icalendar/__init__.py -> build/lib/icalendar copying src/icalendar/windows_to_olson.py -> build/lib/icalendar copying src/icalendar/timezone_cache.py -> build/lib/icalendar copying src/icalendar/prop.py -> build/lib/icalendar copying src/icalendar/caselessdict.py -> build/lib/icalendar copying src/icalendar/tools.py -> build/lib/icalendar copying src/icalendar/parser.py -> build/lib/icalendar copying src/icalendar/cli.py -> build/lib/icalendar copying src/icalendar/cal.py -> build/lib/icalendar copying src/icalendar/parser_tools.py -> build/lib/icalendar creating build/lib/icalendar/tests copying src/icalendar/tests/test_issue_322_single_strings_characters_split_into_multiple_categories.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_unit_parser_tools.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_recurrence.py -> build/lib/icalendar/tests copying src/icalendar/tests/__init__.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_348_exception_parsing_value.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_cli_tool.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_500_vboolean_for_parameter.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_unit_tools.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_time.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_unit_cal.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_318_skip_default_parameters.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_168_parsing_invalid_calendars_no_warning.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_icalendar.py -> build/lib/icalendar/tests copying src/icalendar/tests/conftest.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_fixed_issues.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_557_encode_native_parameters.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_unit_caselessdict.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_27_period.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_issue_165_missing_event.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_examples.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_property_params.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_timezoned.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_with_doctest.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_equality.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_multiple.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_components_break_on_bad_ics.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_parsing.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_encoding.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_unit_prop.py -> build/lib/icalendar/tests copying src/icalendar/tests/test_period.py -> build/lib/icalendar/tests creating build/lib/icalendar/tests/hypothesis copying src/icalendar/tests/hypothesis/test_fuzzing.py -> build/lib/icalendar/tests/hypothesis running egg_info creating src/icalendar.egg-info writing src/icalendar.egg-info/PKG-INFO writing dependency_links to src/icalendar.egg-info/dependency_links.txt writing entry points to src/icalendar.egg-info/entry_points.txt writing requirements to src/icalendar.egg-info/requires.txt writing top-level names to src/icalendar.egg-info/top_level.txt writing manifest file 'src/icalendar.egg-info/SOURCES.txt' reading manifest file 'src/icalendar.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files matching '*.pyc' found under directory 'src/icalendar' warning: no previously-included files matching '*~' found under directory 'src/icalendar' adding license file 'LICENSE.rst' writing manifest file 'src/icalendar.egg-info/SOURCES.txt' copying src/icalendar/tests/test_create_release.sh -> build/lib/icalendar/tests creating
Bug#1069843: zarr: FTBFS: failing tests
Package: src:zarr Version: 2.17.2+ds-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild dh_auto_build -O--buildsystem=pybuild I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" module I: pybuild base:311: python3.12 -m build --skip-dependency-check --no-isolation --wheel --outdir /<>/.pybuild/cpython3_3.12_zarr * Building wheel... running bdist_wheel running build running build_py creating build creating build/lib creating build/lib/zarr copying zarr/hierarchy.py -> build/lib/zarr copying zarr/__init__.py -> build/lib/zarr copying zarr/storage.py -> build/lib/zarr copying zarr/meta_v1.py -> build/lib/zarr copying zarr/creation.py -> build/lib/zarr copying zarr/types.py -> build/lib/zarr copying zarr/util.py -> build/lib/zarr copying zarr/core.py -> build/lib/zarr copying zarr/indexing.py -> build/lib/zarr copying zarr/codecs.py -> build/lib/zarr copying zarr/convenience.py -> build/lib/zarr copying zarr/errors.py -> build/lib/zarr copying zarr/version.py -> build/lib/zarr copying zarr/attrs.py -> build/lib/zarr copying zarr/n5.py -> build/lib/zarr copying zarr/context.py -> build/lib/zarr copying zarr/sync.py -> build/lib/zarr copying zarr/meta.py -> build/lib/zarr creating build/lib/zarr/_storage copying zarr/_storage/__init__.py -> build/lib/zarr/_storage copying zarr/_storage/absstore.py -> build/lib/zarr/_storage copying zarr/_storage/v3.py -> build/lib/zarr/_storage copying zarr/_storage/store.py -> build/lib/zarr/_storage copying zarr/_storage/v3_storage_transformers.py -> build/lib/zarr/_storage creating build/lib/zarr/tests copying zarr/tests/test_sync.py -> build/lib/zarr/tests copying zarr/tests/__init__.py -> build/lib/zarr/tests copying zarr/tests/test_meta.py -> build/lib/zarr/tests copying zarr/tests/test_core.py -> build/lib/zarr/tests copying zarr/tests/test_dim_separator.py -> build/lib/zarr/tests copying zarr/tests/test_storage_v3.py -> build/lib/zarr/tests copying zarr/tests/test_convenience.py -> build/lib/zarr/tests copying zarr/tests/test_n5.py -> build/lib/zarr/tests copying zarr/tests/test_storage.py -> build/lib/zarr/tests copying zarr/tests/test_hierarchy.py -> build/lib/zarr/tests copying zarr/tests/util.py -> build/lib/zarr/tests copying zarr/tests/test_attrs.py -> build/lib/zarr/tests copying zarr/tests/test_creation.py -> build/lib/zarr/tests copying zarr/tests/conftest.py -> build/lib/zarr/tests copying zarr/tests/test_info.py -> build/lib/zarr/tests copying zarr/tests/test_filters.py -> build/lib/zarr/tests copying zarr/tests/test_util.py -> build/lib/zarr/tests copying zarr/tests/test_indexing.py -> build/lib/zarr/tests copying zarr/tests/test_meta_array.py -> build/lib/zarr/tests running egg_info creating zarr.egg-info writing zarr.egg-info/PKG-INFO writing dependency_links to zarr.egg-info/dependency_links.txt writing requirements to zarr.egg-info/requires.txt writing top-level names to zarr.egg-info/top_level.txt writing manifest file 'zarr.egg-info/SOURCES.txt' reading manifest file 'zarr.egg-info/SOURCES.txt' adding license file 'LICENSE.txt' writing manifest file 'zarr.egg-info/SOURCES.txt' installing to build/bdist.linux-x86_64/wheel running install running install_lib creating build/bdist.linux-x86_64 creating build/bdist.linux-x86_64/wheel creating build/bdist.linux-x86_64/wheel/zarr copying build/lib/zarr/hierarchy.py -> build/bdist.linux-x86_64/wheel/zarr copying build/lib/zarr/__init__.py -> build/bdist.linux-x86_64/wheel/zarr copying build/lib/zarr/storage.py -> build/bdist.linux-x86_64/wheel/zarr creating build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_sync.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/__init__.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_meta.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_core.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_dim_separator.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_storage_v3.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_convenience.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_n5.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_storage.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_hierarchy.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/util.py -> build/bdist.linux-x86_64/wheel/zarr/tests copying build/lib/zarr/tests/test_attrs.py ->
Bug#1069842: rjava: FTBFS: /usr/bin/ld: cannot find -ldeflate: No such file or directory
Package: src:rjava Version: 1.0-11-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules build dh build --buildsystem R dh_update_autotools_config -O--buildsystem=R cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead dh_autoreconf -O--buildsystem=R dh_auto_configure -O--buildsystem=R dh_auto_build -O--buildsystem=R dh_auto_test -O--buildsystem=R create-stamp debian/debhelper-build-stamp fakeroot debian/rules binary dh binary --buildsystem R dh_testroot -O--buildsystem=R dh_prep -O--buildsystem=R dh_auto_install --destdir=debian/r-cran-rjava/ -O--buildsystem=R I: R Package: rJava Version: 1.0-11 I: Building using R version 4.4.0-1 I: R API version: r-api-4.0 I: Using built-time from d/changelog: Fri, 26 Jan 2024 11:10:09 -0600 mkdir -p /<>/debian/r-cran-rjava/usr/lib/R/site-library R CMD INSTALL -l /<>/debian/r-cran-rjava/usr/lib/R/site-library --clean . "--built-timestamp='Fri, 26 Jan 2024 11:10:09 -0600'" * installing *source* package ‘rJava’ ... files ‘configure’, ‘jri/tools/config.guess’, ‘jri/tools/config.sub’, ‘src/config.h.in’ have the wrong MD5 checksums ** using staged installation checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking for sys/wait.h that is POSIX.1 compatible... yes checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for string.h... (cached) yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for an ANSI C-conforming const... yes configure: checking whether gcc supports static inline... yes checking whether setjmp.h is POSIX.1 compatible... yes checking for gcc options needed to detect all undeclared functions... none needed checking whether sigsetjmp is declared... yes checking whether siglongjmp is declared... yes checking Java support in R... present: interpreter : '/usr/lib/jvm/default-java/bin/java' archiver: '/usr/lib/jvm/default-java/bin/jar' compiler: '/usr/lib/jvm/default-java/bin/javac' header prep.: '' cpp flags : '-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux' java libs : '-L/usr/lib/jvm/default-java/lib/server -ljvm' checking whether Java run-time works... yes checking whether -Xrs is supported... yes checking whether -Xrs will be used... yes checking whether JVM will be loaded dynamically... no checking whether JNI programs can be compiled... yes checking whether JNI programs run... yes checking JNI data types... ok checking whether JRI should be compiled (autodetect)... yes checking whether debugging output should be enabled... no checking whether memory profiling is desired... no checking whether threads support is requested... no checking whether callbacks support is requested... no checking whether JNI cache support is requested... no checking whether headless init is enabled... no checking whether JRI is requested... yes configure: creating ./config.status config.status: creating src/Makevars config.status: creating R/zzz.R config.status: creating src/config.h === configuring in jri (/<>/jri) configure: running /bin/bash ./configure --disable-option-checking '--prefix=/usr/local' 'CC=gcc' 'CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' --cache-file=/dev/null --srcdir=. checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for
Bug#1069838: khard: FTBFS: ERROR: test_query (unittest.loader._FailedTest.test_query)
Package: src:khard Version: 0.19.1-2 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules build dh build --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:311: python3.12 setup.py config running config I: pybuild base:311: python3.11 setup.py config running config debian/rules override_dh_auto_build make[1]: Entering directory '/<>' cd doc && \ make html && \ make text && \ make man make[2]: Entering directory '/<>/doc' Running Sphinx v7.2.6 making output directory... done [2K[AutoAPI] Reading files... [ 7%] /<>/khard/__init__.py [2K[AutoAPI] Reading files... [ 14%] /<>/khard/khard.py [2K[AutoAPI] Reading files... [ 21%] /<>/khard/__main__.py [2K[AutoAPI] Reading files... [ 29%] /<>/khard/actions.py [2K[AutoAPI] Reading files... [ 36%] /<>/khard/query.py [2K[AutoAPI] Reading files... [ 43%] /<>/khard/carddav_object.py [2K[AutoAPI] Reading files... [ 50%] /<>/khard/address_book.py [2K[AutoAPI] Reading files... [ 57%] /<>/khard/version.py [2K[AutoAPI] Reading files... [ 64%] /<>/khard/cli.py [2K[AutoAPI] Reading files... [ 71%] /<>/khard/formatter.py [2K[AutoAPI] Reading files... [ 79%] /<>/khard/config.py [2K[AutoAPI] Reading files... [ 86%] /<>/khard/helpers/__init__.py [2K[AutoAPI] Reading files... [ 93%] /<>/khard/helpers/typing.py [2K[AutoAPI] Reading files... [100%] /<>/khard/helpers/interactive.py [2K[AutoAPI] Mapping Data... [ 7%] /<>/khard/__init__.py [2K[AutoAPI] Mapping Data... [ 14%] /<>/khard/khard.py [2K[AutoAPI] Mapping Data... [ 21%] /<>/khard/__main__.py [2K[AutoAPI] Mapping Data... [ 29%] /<>/khard/actions.py [2K[AutoAPI] Mapping Data... [ 36%] /<>/khard/query.py [2K[AutoAPI] Mapping Data... [ 43%] /<>/khard/carddav_object.py [2K[AutoAPI] Mapping Data... [ 50%] /<>/khard/address_book.py [2K[AutoAPI] Mapping Data... [ 57%] /<>/khard/version.py [2K[AutoAPI] Mapping Data... [ 64%] /<>/khard/cli.py [2K[AutoAPI] Mapping Data... [ 71%] /<>/khard/formatter.py [2K[AutoAPI] Mapping Data... [ 79%] /<>/khard/config.py [2K[AutoAPI] Mapping Data... [ 86%] /<>/khard/helpers/__init__.py [2K[AutoAPI] Mapping Data... [ 93%] /<>/khard/helpers/typing.py [2K[AutoAPI] Mapping Data... [100%] /<>/khard/helpers/interactive.py [AutoAPI] Rendering Data... [ 7%] khard [AutoAPI] Rendering Data... [ 14%] khard.khard [AutoAPI] Rendering Data... [ 21%] khard.__main__ [AutoAPI] Rendering Data... [ 29%] khard.actions [AutoAPI] Rendering Data... [ 36%] khard.query [AutoAPI] Rendering Data... [ 43%] khard.carddav_object [AutoAPI] Rendering Data... [ 50%] khard.address_book [AutoAPI] Rendering Data... [ 57%] khard.version [AutoAPI] Rendering Data... [ 64%] khard.cli [AutoAPI] Rendering Data... [ 71%] khard.formatter [AutoAPI] Rendering Data... [ 79%] khard.config [AutoAPI] Rendering Data... [ 86%] khard.helpers [AutoAPI] Rendering Data... [ 93%] khard.helpers.typing [AutoAPI] Rendering Data... [100%] khard.helpers.interactive [autosummary] generating autosummary for: bench.rst, commandline.rst, contributing.rst, davcontroller.rst, index.rst, indices.rst, man.rst, man/khard.conf.rst, man/khard.rst, scripting.rst building [mo]: targets for 0 po files that are out of date writing output... building [html]: targets for 10 source files that are out of date updating environment: [new config] 25 added, 0 changed, 0 removed [2Kreading sources... [ 4%] autoapi/index [2Kreading sources... [ 8%] autoapi/khard/__main__/index [2Kreading sources... [ 12%] autoapi/khard/actions/index [2Kreading sources... [ 16%] autoapi/khard/address_book/index [2Kreading sources... [ 20%] autoapi/khard/carddav_object/index [2Kreading sources... [ 24%] autoapi/khard/cli/index [2Kreading sources... [ 28%] autoapi/khard/config/index [2Kreading sources... [ 32%] autoapi/khard/formatter/index [2Kreading sources... [ 36%] autoapi/khard/helpers/index [2Kreading sources... [ 40%] autoapi/khard/helpers/interactive/index [2Kreading sources... [ 44%] autoapi/khard/helpers/typing/index [2Kreading sources... [ 48%] autoapi/khard/index [2Kreading sources... [ 52%] autoapi/khard/khard/index [2Kreading sources... [ 56%] autoapi/khard/query/index [2Kreading sources... [ 60%] autoapi/khard/version/index [2Kreading sources... [ 64%] bench [2Kreading sources... [ 68%] commandline [2Kreading sources... [ 72%] contributing [2Kreading sources... [ 76%] davcontroller [2Kreading sources... [ 80%] index [AutoAPI] Adding AutoAPI TOCTree [autoapi/index] to index.rst [2Kreading sources... [ 84%] indices [2Kreading sources... [ 88%] man [2Kreading sources... [ 92%] man/khard [2Kreading sources... [ 96%] man/khard.conf [2Kreading sources... [100%] scripting
Bug#1069839: libcommons-fileupload-java: FTBFS: failing tests
Package: src:libcommons-fileupload-java Version: 1.5-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary dh_update_autotools_config dh_autoreconf dh_auto_configure mh_patchpoms -plibcommons-fileupload-java --debian-build --keep-pom-version --maven-repo=/<>/debian/maven-repo dh_auto_build /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. [INFO] Scanning for projects... [WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded from it before. [WARNING] The artifact org.apache.maven.plugins:maven-clean-plugin:jar:2.5 has been relocated to org.apache.maven.plugins:maven-clean-plugin:jar:3.2.0 [WARNING] The artifact org.apache.maven.plugins:maven-resources-plugin:jar:2.6 has been relocated to org.apache.maven.plugins:maven-resources-plugin:jar:3.3.0 [WARNING] The artifact org.apache.maven.plugins:maven-jar-plugin:jar:2.4 has been relocated to org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0 [WARNING] The artifact org.apache.maven.plugins:maven-compiler-plugin:jar:3.1 has been relocated to org.apache.maven.plugins:maven-compiler-plugin:jar:3.10.1 [WARNING] The artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4 has been relocated to org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.3 [WARNING] The POM for org.apache.maven.plugins:maven-install-plugin:jar:2.4 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-install-plugin:2.4: Plugin org.apache.maven.plugins:maven-install-plugin:2.4 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-install-plugin:jar:2.4 has not been downloaded from it before. [WARNING] The POM for org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-deploy-plugin:2.7: Plugin org.apache.maven.plugins:maven-deploy-plugin:2.7 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-deploy-plugin:jar:2.7 has not been downloaded from it before. [WARNING] The POM for org.apache.maven.plugins:maven-site-plugin:jar:3.3 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-site-plugin:3.3: Plugin org.apache.maven.plugins:maven-site-plugin:3.3 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-site-plugin:jar:3.3 has not been downloaded from it before. [WARNING] The POM for org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-antrun-plugin:1.3: Plugin org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies could not be resolved: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.apache.maven.plugins:maven-antrun-plugin:jar:1.3 has not been downloaded from it before. [WARNING] The POM for org.apache.maven.plugins:maven-assembly-plugin:jar:2.2-beta-5 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5: Plugin org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its dependencies could not be resolved: Cannot access central
Bug#1069840: maven-dependency-analyzer: FTBFS: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project maven-dependency-analyz
Package: src:maven-dependency-analyzer Version: 1.13.0-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules build dh build dh_update_autotools_config dh_autoreconf dh_auto_configure mh_patchpoms -plibmaven-dependency-analyzer-java --debian-build --keep-pom-version --maven-repo=/<>/debian/maven-repo dh_auto_build /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/<> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<>/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian -Dmaven.repo.local=/<>/debian/maven-repo --batch-mode package -DskipTests -Dnotimestamp=true -Dlocale=en_US OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release. [INFO] Scanning for projects... [INFO] [INFO] -< org.apache.maven.shared:maven-dependency-analyzer >-- [INFO] Building Apache Maven Dependency Analyzer 1.13.0 [INFO] [ jar ]- [WARNING] The artifact org.apache.maven.plugins:maven-resources-plugin:jar:2.6 has been relocated to org.apache.maven.plugins:maven-resources-plugin:jar:3.3.0 [WARNING] The artifact org.apache.maven.plugins:maven-compiler-plugin:jar:3.1 has been relocated to org.apache.maven.plugins:maven-compiler-plugin:jar:3.10.1 [WARNING] The artifact org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4 has been relocated to org.apache.maven.plugins:maven-surefire-plugin:jar:2.22.3 [WARNING] The artifact org.apache.maven.plugins:maven-jar-plugin:jar:2.4 has been relocated to org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0 [INFO] [INFO] --- maven-resources-plugin:3.3.0:resources (default-resources) @ maven-dependency-analyzer --- [INFO] skip non existing resourceDirectory /<>/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ maven-dependency-analyzer --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 19 source files to /<>/target/classes [INFO] /<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java: /<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java uses or overrides a deprecated API. [INFO] /<>/src/main/java/org/apache/maven/shared/dependency/analyzer/DefaultProjectDependencyAnalyzer.java: Recompile with -Xlint:deprecation for details. [INFO] [INFO] --- sisu-maven-plugin:0.3.5:main-index (index-project) @ maven-dependency-analyzer --- [INFO] [INFO] --- maven-resources-plugin:3.3.0:testResources (default-testResources) @ maven-dependency-analyzer --- [INFO] skip non existing resourceDirectory /<>/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @ maven-dependency-analyzer --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 11 source files to /<>/target/test-classes [INFO] /<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java: /<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java uses unchecked or unsafe operations. [INFO] /<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ProjectDependencyAnalysisTest.java: Recompile with -Xlint:unchecked for details. [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java:[67,13] exception java.io.IOException is never thrown in body of corresponding try statement [INFO] 1 error [INFO] - [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.735 s [INFO] Finished at: 2024-04-25T13:27:25Z [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project maven-dependency-analyzer: Compilation failure [ERROR] /<>/src/test/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtilsTest.java:[67,13] exception java.io.IOException is never thrown in body of corresponding try statement [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
Bug#1065660: antlr4-maven-plugin: please provide debian-versioned maven coordinates
severity 1065660 serious tags 1065660 + ftbfs thanks Hello. I noticed that chemicaltagger currently FTBFS and I believe it is because of this problem, so to avoid duplicate reports, I'm raising this one to serious. A build log for chemicaltagger is available here: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/chemicaltagger.html By raising the severity of this bug, I'm assuming that this will be eventually fixed in antlr4-maven-plugin and chemicaltagger will not need to be changed to build again, but I really have no idea if such thing will happen. If it does not, we would need a different FTBFS bug for chemicaltagger so that it's fixed there. Thanks.
Bug#1069814: golang-github-aydinnyunus-blockchain: FTBFS: Tries network access during build
Package: src:golang-github-aydinnyunus-blockchain Version: 0.0~git20220623.647ebea-1 Severity: serious Tags: ftbfs Dear maintainer: This package tries network access during build: = TESTING ADDRESSES = querying...https://blockchain.info/multiaddr?active=162FjqU7RYdojnejCDe6zrPDUpaLcv9Hhq|1K3Vs8tPu2YkAoWmrkjUQVJuxr7wgPP 3Wf Get "https://blockchain.info/multiaddr?active=162FjqU7RYdojnejCDe6zrPDUpaLcv9Hhq|1K3Vs8tPu2YkAoWmrkjUQVJuxr7wgPP3Wf": dial tcp: lookup blockchain.info on [::1]:53: read udp [::1]:44899->[::1]:53: read: connection refused--- PASS: TestGe tAddresses (0.00s) This is why it fails to build in reproducible builds: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-aydinnyunus-blockchain.html Thanks.
Bug#1053334: galera-4: FTBFS because of expired certificates
El 25/4/24 a las 7:15, Otto Kekäläinen escribió: Bullseye oldstable update request filed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069802 You can +1 it if you want to show support. Thanks a lot! We don't +1 because this is not twitter/facebook :-) but I have just made a comment to explain why the update is important. Thanks.
Bug#1069802: bullseye-pu: package galera-4 26.4.18-0+deb11u1
Dear Release Managers: Since I reported bug #1053334, I'd like to emphasize on this item: * New upstream release includes multiple Debian build and post-build test failure fixes: - Generate keys and certificates for SSL tests (Closes: #1053334) This is a FTBFS bug due to expiring certificates and the main reason I requested Otto for an update. Without this update, anybody trying to rebuild galera-4 from sources will see how the build unexpectedly fails. Thanks.
Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29
Jeremy Bícha wrote: It was also marked as severity important instead of RC because it does not affect official buildds. Not true: https://buildd.debian.org/status/logs.php?pkg=libsoup2.4=all See also: https://buildd.debian.org/status/logs.php?pkg=gcr=all and also: https://buildd.debian.org/status/logs.php?pkg=gcr4=amd64 And regardless of the severity of the day, you were *explicitly* asked by Sebastian Ramacher to disable *or* fix the flaky tests: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057562#17 Note that it's "or", nobody is asking you to act heroically and spend a time that you don't have. We just want to build the packages without random failures, and for that it's enough to disable the tests that we know to be broken. It can't be so much difficult.
Bug#1069415: libsoup2.4: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 29
retitle 1069415 libsoup2.4: FTBFS: failing tests
thanks
El 24/4/24 a las 18:26, Andreas Metzler escribió:
On 2024-04-20 Lucas Nussbaum wrote:
Source: libsoup2.4
Version: 2.74.3-7
Severity: serious
Justification: FTBFS
[...]
(hsts-test:547071): GLib-Net-WARNING **: 04:03:06.247: Failed to load TLS
database: System trust contains zero trusted certificates; please investigate
your GnuTLS configuration
FWIW I could not reproduce this on amdahl.debian.org, the build
succeeded.
This is not arm64-specific. It also happens on amd64:
See how the autobuilder for Arch:all had to try 3 times to build the package:
https://buildd.debian.org/status/logs.php?pkg=libsoup2.4=2.74.3-7=all
If you want to debug it or just verify that the test fails very easily on
certain
machines, contact me privately and I will gladly give you access to a machine
where it happens all the time.
In my opinion, the test has a very low quality, so if there is not willingness,
capacity, or just time to fix it (which is fine), then it should be disabled,
because in its current state it is a waste of time for everybody.
No, I don't buy the theory that this is a good way to "remind" that there
is a flaky test. A Release Manager made a similar request ("fix it or disable
it")
in Bug #1057562 but the bug was downgraded again and the request from the
Release
Manager continues to be ignored.
Thanks.
Bug#1069698: lists.debian.org: Automatic replies from Apple Support China
Package: lists.debian.org Dear Debian listmasters: Many people report that messages sent to certain n...@bugs.debian.org addresses receive automatic replies from Apple Support China. Apparently it does not happen with every bug report, but only with those which are RC, which suggests that there may be one subscriber of debian-bugs-rc with a forwarding rule causing the automatic replies. A bisection method has been suggested to discover the address causing the replies, but I believe it would be possible to do it in one shot by sending "fake" email messages (appearing to come from the list) to every subscriber of debian-bugs-rc, with different From: fields. (This is actually the idea behind VERP, except that the forwarding rule causing the problem is so broken that we would have to use the real From: instead of the envelope from). Thanks.
Bug#1064459: refining DEP17 patches for glibc and base-files
I've updated my demo repository with your patch. https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo/-/commit/6425c8cde53596199cd37bb1625d1dfb2a4b74d0 Great. I'll take a look. I'm happy to call it guest upload while I find team upload slightly misleading. I avoid patching changelogs in the demo to avoid the need for unnecessary rebasing. It's a functional demo. For util-linux, I think Chris will send me an encrypted version of a signed .changes file such that I only perform the upload not even the signing. Please let me know if you prefer that approach. I'd like to use that approach too. At least until I make the package reproducible-from-git (which currently it's not). BTW: There is a minor glitch in postinst which I introduced a long time ago: /var/run and /var/lock are created as real directories, but then, at debootstrap time, the function migrate_directory() function converts them to symlinks. (I do not remember why it's done that way, maybe shipping a real symlink would confuse dpkg?) Do you think I should try to do this in a more orthodox way? Or maybe it does not worth the effort? (I ask because, as in the usr-merge patch, this is also about "avoiding dpkg to follow symlinks") Thanks.
Bug#1053334: galera-4: FTBFS because of expired certificates
El 22/4/24 a las 8:47, Otto Kekäläinen escribió: I was able to reproduce this for Bookworm both locally and in CI at https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032 After importing latest upstream build/test passes: https://salsa.debian.org/otto/galera/-/jobs/5624466 Stable upload request filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069639 Thanks a lot! What about bullseye, which is also a supported distribution? I have not reached the point where I want to do NMUs for these kind of bugs, but if this were my package, I would certainly do an upload for bullseye as well. If I can be of any help, please say so. Thanks.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
El 15/4/24 a las 22:26, Bill Allombert escribió: On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: Package: base-files Version: 12.4+deb12u1 Followup-For: Bug #1039979 Control: tags -1 patch I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so. At least the /var/run directory is also created as a symlink to ../run by tmpfiles.d: /usr/lib/tmpfiles.d/var.conf from the systemd package contains: L /var/run - - - - ../run Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ? /usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is. Note that you are using here the words "fix" and "correct" to mean "what policy says". However, the point the reporter was trying to make (if I understood correctly) is that there is already a "trend" by which it's more useful to have those symlinks as relative, and the systemd reference was just to highlight such trend. So the question would be: Is policy really correct by requesting those symlinks to be absolute considering that there seems to be a significant amount of people (including systemd upstream) who consider more useful for them to be relative? Thanks.
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
El 25/3/24 a las 20:12, Chris Lamb escribió: Alberto Bertogli wrote: If you know of a functional official image that I can use to try to reproduce the problem, or recently-tested steps I can follow to get a working qemu install, please let me know. Alas, I can't actually be helpful here. There are no official images as far as I know… and somewhat annoyingly I (ie. a Debian Developer) actually have access to some machines set aside for this purpose. I call this "annoying" because I naturally can't then give you direct SSH access transitively — but I can proxy ideas, of course. Hi. I can't offer ssh access either (for now), but I've checked and this error may be reproduced easily on an arm64 machine using an armel chroot. Several cloud vendors (like GCP, AWS or Hetzner) offer arm64 machines, billed hourly and relatively cheap. Also (but only if your stomach allows it :-), Oracle Cloud has arm64 machines in their Free Tier. In this case I think they only have Ubuntu and not Debian, but this would be not matter if you are using a Debian chroot. Thanks.
Bug#1064459: refining DEP17 patches for glibc and base-files
Hi. I've added two commits, one to create symlinks with a "shell" for, and the last one for a sample changelog (because this is really a "team upload" or a "guest upload" more than a NMU). I think for simplicity it's ok if you skip the changelog part in your repo. Thanks.
Bug#1064459: refining DEP17 patches for glibc and base-files
El 17/4/24 a las 20:07, Helmut Grohne escribió: Please let me know when you did your editorial changes such that I can replace my patch with yours and retest. I did those minor changes in the branch wip-202404-usrmerge, just after your patch. (If you adopt those changes, I'll rewrite the branch to be a single commit again) Additionally (but did not have time to look at it yet), I'd like this line: $(foreach d,$(USR_MERGE),ln -s usr/$(d) debian/base-files/$(d) &&) : to be a "shell" for instead (similar to the way debian/triggers is created). The foreach feature is perfect in the dh_installdirs line, but in this case, I would prefer shell code, for readability. BTW: I am completely ok that we wait until the t64 transition is finished. Thanks.
Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering
I saw in #604918 that /etc/profile is deliberately not treated as a conffile. Is there any way to get the new version installed on package upgrade, other than an external configuration management system such as Ansible? The way /etc/profile is handled changed slightly in version 6.10, one year and a half after the bug you mention. Now, if you did not modify your /etc/profile file, it will be updated to the new default. If you are curious about how it's done, see update_to_current_default() function in the postinst. If you did modify it, ansible would be appropriate. Thanks.
Bug#1012690: pagetools: FTBFS with netpbm11
tags 1012690 + patch
thanks
Hello Víctor.
I believe the attached patch will be enough to fix the build failure
(but you might want to update other things as well).
I would gladly be your sponsor if you still need it.
Thanks.diff --git a/debian/control b/debian/control
index 0e9a667..9b33160 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: graphics
Priority: optional
Maintainer: Víctor Cuadrado Juan
Standards-Version: 4.1.3
-Build-Depends: debhelper (>= 11), libnetpbm10-dev, libtiff5-dev
+Build-Depends: debhelper (>= 11), libnetpbm11-dev, libtiff5-dev
Homepage: https://sourceforge.net/projects/pagetools/
Vcs-Git: https://salsa.debian.org/viccuad-guest/pagetools.git
Vcs-Browser: https://salsa.debian.org/viccuad-guest/pagetools
diff --git a/formats/pbmfact.cpp b/formats/pbmfact.cpp
index c65fef5..2374ba5 100644
--- a/formats/pbmfact.cpp
+++ b/formats/pbmfact.cpp
@@ -19,7 +19,7 @@
#include
extern "C"{
-#include
+#include
}
namespace pagetools{
Bug#1069279: loading /etc/profile.d scripts should enforce consistent ordering
El 19/4/24 a las 11:30, Dave Holland escribió: Package: base-files Version: 12.4+deb12u5 The fragment in /etc/profile (copied from /usr/share/base-files/profile) does not enforce a particular locale when generating the list of /etc/profile.d/*.sh files to load. This means that the ordering of those scripts is not predictable, but depends on the locale (LC_ALL environment variable) of the user logging in, when passed by sshd. This can lead to subtle misbehaviour at best, or outright breakage at worst. A user should not be able to influence the admin-configured script ordering which is set by those filenames. Suggested fix: explicitly set LC_ALL=C, to match the sort behaviour of run-parts, and if necessary reset it afterwards. Thanks for the report. Is this not already addressed by the proposed patch in Bug #885414, in which we explicitly use run-parts --list to get the files to be processed? Thanks.
Bug#1069263: sendfile: File in /etc/profile.d has an invalid filename
Package: src:sendfile Version: 2.1b.20080616-10 Dear maintainer: The file /etc/profile.d/sendfile does not have .sh suffix, so it's not sourced by /etc/profile at all. I noticed this because I'm planning to improve the way files at /etc/profile.d are read (see Bug#885414). The plan is to use a regexp (instead of just *.sh), but the requirement that the files have .sh suffix will remain, as it's used to differentiate shell snippets from csh snippets. Suggest using "sendfile.sh" instead, but maybe you have to do additional things to remove the old conffile if it did not change. Thanks.
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
El 18/4/24 a las 22:17, Richard Lewis escribió: '^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$' Hi. I confirm that this is appropriate for what we distribute: What about local scripts added by users (which this change might prevent loading): perhaps a NEWS.Debian entry would suffice? Are there any guidelines about when NEWS.Debian should be used and when the Release Notes? (I'd like to avoid spamming the users with non-important information) Thanks.
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
tags 885414 - help
thanks
Vincent Lefevre wrote:
'^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$'
Hi. I confirm that this is appropriate for what we distribute:
wget -q -O - http://deb.debian.org/debian/dists/unstable/main/Contents-amd64.gz
| gzip -d | awk '/etc\/profile.d/ { print $1 }'
yields:
etc/profile.d/PackageKit.sh
etc/profile.d/apps-bin-path.sh
etc/profile.d/flatpak.sh
etc/profile.d/gawk.csh
etc/profile.d/gawk.sh
etc/profile.d/guix.sh
etc/profile.d/lammps.csh
etc/profile.d/lammps.sh
etc/profile.d/lmod.sh
etc/profile.d/maliit-framework.sh
etc/profile.d/modules.sh
etc/profile.d/safe-rm.sh
etc/profile.d/sendfile
etc/profile.d/sumo.csh
etc/profile.d/sumo.sh
etc/profile.d/sxmo_init.sh
etc/profile.d/toolbox.sh
etc/profile.d/vte-2.91.sh
etc/profile.d/vte.csh
The regexp covers that but not the *.csh ones (now as expected)
and not sendfile, but that's a bug in sendfile.
Thanks.
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
So I think that the --regex argument should be '^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$' Thanks a lot! Yes, this is the kind of feedback I need. Next I'd like to match such regexp with the files in /etc/profile.d that may be obtained from the Contents.gz file in the archives to be sure that the regexp will work. Thanks.
Bug#964941: base-files: please maintain base-files in a VCS such as git on salsa.d.o
severity 964941 normal thanks Hi. I'm going to answer to all three here. El 13/7/20 a las 4:30, Paul Wise escribió: Source: base-files Severity: wishlist It would be great if you could maintain base-files in a VCS such as git on salsa.d.o. If you would like to do that, please import the existing source packages on snapshot.d.o into the VCS repository first. One option for importing the old source packages is gbp: $ git init $ gbp import-dscs --debsnap base-files If you have a slow network connection you can also download all the files on lw08.debian.org, which is close to snapshot.d.o: $ ssh lw08.debian.org -tt debsnap -v base-files $ scp -r lw08.debian.org:source-base-files . $ mkdir base-files $ cd base-files $ git init $ gbp import-dscs ../source-base-files/*.dsc Thanks a lot for the hints! Yes, I'd like to do that, *some* day. While I'm still a little bit skeptical about putting everything in git, I agree that it would be a good thing for native packages like this one (but *not* necessarily for the reasons I often hear). I'm raising this to "normal" to reflect that I also want to do that. Note, however, that this less a bug in the package and more a request to change my workflow, and, as I once said to Geert Stappers in another report: We can NMU a package, but we can't NMU a workflow. Anyway, I've started this as a test: https://salsa.debian.org/sanvila/base-files-not-yet It has no history yet (except yesterday's changes from 13 to 13.1), and I believe the name speaks for itself: This is meant to be an experiment. If it goes well and I end up being comfortable with it, I'll add the missing bits and make it official. I've decided to start this to share the work of usr-merge with Helmut, but it's not an invitation to receive merge requests via salsa, and I still want to discuss things in the BTS, by email. I wonder if there is a salsa setting to make this sort of preferences known to potential contributors (not something hard like disabling merge requests completely but something like "please use the BTS"). I'm not sure if gbp will automatically understand the correct branch structure for the package based on the stable-pu updates, but if it does not you can use the second method and manually do the branching. Yes, that's something that has to be done carefully. Gioele Barabucci wrote: https://salsa.debian.org/gioele/base-files Thanks for the offer, but I'll try to make a better repo when I have time. As Paul pointed out above, the point releases do not belong in the master branch, they should be forked from master at some point. Also, I have some tarballs here which apparently are missing from snapshot.d.o. Lee Garret wrote: I'm trying to understand why /var/local/ is root:staff (#1039973), and a VCS would really help with that. The /var/local thing has been there for as far as I have been the maintainer of base-files. I'd like to deprecate it, as we already did with /usr/local, but there will always be somebody who will complain. It would also make it easier for you to accept patches for bugs. I think in many cases it would really not. Merely "accepting" patches is trivial in either case. Most of the time, the real work is ensuring that nothing will break, and salsa does not help here. For an example, see #885414. I've tagged it as help because there is a pending task to be done, salsa would not help to do such task. Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
This is actually explained in the last question here: /usr/share/doc/base-files/FAQ Isn't that quite unfortunate? It leaves out any legacy installations (and many people never re- install Debian, but just continuously upgrade it). I mean I can fully understand if it's to fragile to automatically update base-files (not just creating new dirs, but e.g. also changed directories), but: - Wouldn't it be possible to have a small tool that is manually run and which e.g. compare the current situation with what a pristine installation would get and that spits out some commands that would adapt this... or per default be like --dry-run and only with some extra param do everything? - Or at least *if* something changes - which is anyway quite rate - it should IMO into NEWS.Debian and the release notes, so that people that upgrade can catch up. I think you might be overestimating the importance of this. An empty directory does not have any "functionality" by itself. It's just a placeholder, and it's there mainly to satisfy FHS compliance tests, nothing more. In Debian, all the stuff is in /usr/bin et al. We don't really need any of those directories. The end user is not actually missing anything important by having more or less empty directories in /usr/local. The typical ./configure script used by autoconf and friends which would install things in /usr/local/libexec will probably do so regardless of the directory already existing or not. So, on the side of NEWS.Debian, no, I don't think this is relevant at all. We should not bother the end user for non-important things. Regarding your idea of writing a script which "updates" all those minor things: Feel free to do so, but I don't think it belongs to base-files. In fact, there are a lot of things which differ between an upgraded system and a newly installed system, and the differences due to more or less empty directories in /usr/local are probably the least important of all of them. BTW: Having said that, I should add that I share part of your feelings. I used to maintain several computer labs, and sometimes I used to do upgrades from oldstable to stable using ansible. After upgrading the packages, I often had additional recipes to achieve exactly what you mention: that an upgraded system is as close as possible to a newly installed system. If you have time and motivation to work on such things, here is an idea: investigate what kind of tool we could use to replace deborphan, since it has just been removed from trixie and sid. Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
El 17/4/24 a las 23:16, Christoph Anton Mitterer escribió: Hey. FYI: I have upgraded to 13.1, but still didn't get a /usr/local/libexec. Guess that's because $2 in the script is not empty? Yes. An empty $2 means that the package is installed for the very first time, i.e. installed by debootstrap. This is actually explained in the last question here: /usr/share/doc/base-files/FAQ Thanks.
Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile
tags 885414 + help
thanks
Hello. Sorry for the late reply.
The problem, more than lack of quoting, is that there is no specification
anywhere about what should be allowed and what should not.
But we are not late to begin such specification.
Here is my current plan:
--- a/share/profile
+++ b/share/profile
@@ -25,7 +25,7 @@ if [ "${PS1-}" ]; then
fi
if [ -d /etc/profile.d ]; then
- for i in /etc/profile.d/*.sh; do
+ for i in $(run-parts --list --regex '^[a-zA-Z0-9._-]+.sh$' /etc/profile.d);
do
if [ -r $i ]; then
. $i
fi
Now the pending task is to see if the above regex is enough for all the snippets
that the current packages in trixie/sid put in /etc/profile.d.
I'm tagging this as "help" to see if some kind soul wants to check that and
share their findings.
Thanks.
Bug#1064459: refining DEP17 patches for glibc and base-files
El 28/2/24 a las 21:19, Helmut Grohne escribió: Niels Thykier made me aware of dh_installdeb -D. Using it avoids the need for a pile of .in files in base-files. I hope you like this refactoring. Let me know if not. Nice feature indeed. To simplify the usr-merge patch, I've adopted the -D change in debian/postinst *before* we apply the usr-merge patch. Please take a look at branch "wip-202404-usrmerge" here: https://salsa.debian.org/sanvila/base-files-not-yet/-/tree/wip-202404-usrmerge?ref_type=heads (The repository name speaks for itself... I'm still not comfortable enough with salsa, but I'd like to experiment and see how it goes). I've rebased the patch relative to version 13.1 which I have just uploaded. If the rebase is ok, I'd like to make some minor editorial changes there as well. Thanks.
Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly
Package: openstack-dashboard Version: 3:24.0.0-2 Affects: src:designate-dashboard Severity: serious Justification: Breaks other packages Dear maintainer: During an incremental rebuild of all packages in trixie, package "designate-dashboard" failed to build due to a postinst error in openstack-dashboard: [...] 2717 static files copied to '/var/lib/openstack-dashboard/static'. /usr/lib/python3/dist-packages/django/conf/__init__.py:267: RemovedInDjango50Warning: The USE_L10N setting is deprecat ed. Starting with Django 5.0, localized formatting of data will always be enabled. For example Django will display num bers and dates using the format of the current locale. warnings.warn(USE_L10N_DEPRECATED_MSG, RemovedInDjango50Warning) /usr/lib/python3/dist-packages/debreach/__init__.py:6: DeprecationWarning: distutils Version classes are deprecated. U se packaging.version instead. version_info = version.StrictVersion(__version__).version CommandError: An error occurred during rendering serial_console.html: Syntax error: Found 'inline-blo' but expected one of ADD, ALPHA_FUNCTION, BANG_IMPORTANT, BAREWORD, COLOR, DOUBLE_QUOTE, FNCT, IF_FUNCTION, INTERP_START, LITERAL_FUNCTION, LPAR, NOT, NUM, SIGN, SINGLE_QUOTE, URL_FUNCTION, VAR Compressing... dpkg: error processing package openstack-dashboard (--configure): installed openstack-dashboard package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of sbuild-build-depends-main-dummy: sbuild-build-depends-main-dummy depends on openstack-dashboard; however: Package openstack-dashboard is not configured yet. dpkg: error processing package sbuild-build-depends-main-dummy (--configure): dependency problems - leaving unconfigured Processing triggers for ca-certificates (20240203) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Errors were encountered while processing: openstack-dashboard sbuild-build-depends-main-dummy E: Sub-process /usr/bin/dpkg returned an error code (1) apt-get failed. The above is just how the build ends and not necessarily the most relevant part. If required, the full build log (for designate-dashboard) is available here: https://people.debian.org/~sanvila/build-logs/202404/ Note also how there is a gazillion of error messages like this: Found another file with the destination path 'horizon/lib/angular_schema_form/i18n/angular-locale_az-cyrl-az.js'. It will be ignored since only the first encountered file is collected. If this is not what you want, make sure every static file has a unique path. That's apparently a django-related issue: https://stackoverflow.com/questions/35571256/found-another-file-with-the-destination-path-where-is-that-other-file which I would hope can be fixed as well (maybe it's part of the problem, maybe not, I don't know). About the archive rebuild: The build was made on virtual machines of type m6a.large from AWS, using sbuild and a reduced chroot with only build-essential packages. I can't provide a "recipe" to reproduce the bug because it happens randomly, but I expect the above error messages and the full build log will help to determine the cause. If required, I could provide ssh access to a virtual machine where this random build failure happens, but I strongly suggest that the build log is analyzed first to determine how it could happen. Thanks.
Bug#1069073: lua-mode: FTBFS: failing tests
Package: src:lua-mode
Version: 20210802-3
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules build
dh build --with elpa
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
dh_auto_build
make -j2
make[1]: Entering directory '/<>'
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
version is 20210802
make[1]: Leaving directory '/<>'
dh_elpa_test
buttercup -L .
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Warning (buttercup): Found duplicate spec names in suite: ("lua-skip-ws-and-comments-forward respects
limit when escaping multi-line comment 1: limit=8 \"--[[<1> <2> ]] \\n\"")
Running 392 out of 410 specs.
Test electric mode
works with curly braces
[32m works with curly braces[0m (3.66ms)
works with parentheses
[32m works with parentheses[0m (0.97ms)
works with end
[32m works with end[0m (1.13ms)
works with else
[32m works with else[0m (1.13ms)
works with elseif
[32m works with elseif[0m (1.16ms)
Electric pair mode
skips parens when electric-pair-skip-self is t
[32m skips parens when electric-pair-skip-self is t[0m (1.60ms)
Test fill-paragraph
fills single-line comment
[32m fills single-line comment[0m (0.45ms)
fills comment after code
[32m fills comment after code[0m (0.39ms)
fills multiline comment
[33m fills multiline comment[0m[33m PENDING[0m (0.07ms)
does not spill comments into code (issue #25)
[32m does not spill comments into code (issue #25)[0m (0.38ms)
Test fill-paragraph preserves point position
doesn't move point if nothing has changed
[32m doesn't move point if nothing has changed[0m (0.96ms)
doesn't move point in refilled region
[32m doesn't move point in refilled region[0m (2.26ms)
doesn't move point if nothing has changed (multi-line)
[32m doesn't move point if nothing has changed (multi-line)[0m (0.71ms)
Fontification of built-ins
fontifies built-ins
[32m fontifies built-ins[0m (0.27ms)
fontifies built-ins with spaces between members
[32m fontifies built-ins with spaces between members[0m (0.26ms)
doesn't fontify things that look like built-ins
[32m doesn't fontify things that look like built-ins[0m (0.50ms)
fontifies built-in class if method is not built-in
[32m fontifies built-in class if method is not built-in[0m (0.24ms)
fontifies built-ins after concatenation operator
[32m fontifies built-ins after concatenation operator[0m (0.19ms)
Fontification of constants
fontifies constants
[32m fontifies constants[0m (0.20ms)
fontifies constants used as attributes
[32m fontifies constants used as attributes[0m (0.19ms)
Fontification of keywords
fontifies keywords
[32m fontifies keywords[0m (0.27ms)
fontifies keywords used as attributes
[32m fontifies keywords used as attributes[0m (0.24ms)
Fontification of variables
fontifies "local foo, bar, baz = 1, 2, 3"
[32m fontifies "local foo, bar, baz = 1, 2, 3"[0m (0.21ms)
fontifies "local foo, bar, baz"
[32m fontifies "local foo, bar, baz"[0m (0.20ms)
fontifies "local x =" at end of buffer
[32m fontifies "local x =" at end of buffer[0m (0.16ms)
fontifies local "x =" at end of line
[32m fontifies local "x =" at end of line[0m (0.18ms)
does not fontify "for" inside strings
[32m does not fontify "for" inside strings[0m (0.22ms)
fontifies "for x123 ="
[32m fontifies "for x123 ="[0m (0.16ms)
fontifies "for x, y, z"
[32m fontifies "for x, y, z"[0m (0.18ms)
Fontification of function headers
fontifies function (...) headers
[32m fontifies function (...) headers[0m (0.20ms)
fontifies local function (...) headers
[32m fontifies local function (...) headers[0m (0.21ms)
fontifies = function (...) headers
[32m fontifies = function (...) headers[0m (0.19ms)
fontifies local = function (...) headers
[32m fontifies local = function (...) headers[0m (0.20ms)
fontifies parameters in function literals
[32m fontifies parameters in function literals[0m (0.18ms)
fontifies different variations of headers altogether
[32m fontifies different variations of headers altogether[0m (0.41ms)
fontifies headers inside tables
[32m fontifies headers inside tables[0m (0.31ms)
does not fail on issue #59 again
[32m does not fail on issue #59 again[0m (0.30ms)
does not choke on function names with underscores
Bug#1069074: totalopenstation: FTBFS: failing tests
Package: src:totalopenstation Version: 0.5.2-4 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:311: python3.11 setup.py config running config dh_auto_build -O--buildsystem=pybuild I: pybuild base:311: /usr/bin/python3 setup.py build running build running build_py creating /<>/.pybuild/cpython3_3.11/build/totalopenstation copying totalopenstation/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/trimble.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/zeiss_elta_r55.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/nikon_npl_350.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/custom.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models copying totalopenstation/models/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/models creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_polar.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_topcon_gts.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_trimble_are.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_gsi.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_zeiss_r5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_geojson.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_csv.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_zeiss.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_nikon.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_rw5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_sokkia_sdr33.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests copying totalopenstation/tests/test_dxf.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/tests creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/nikon_raw_v200.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/trimble_are.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/topcon_gts.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/sokkia_sdr33.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/conversion.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/zeiss_r5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_tcr_705.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/polar.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_gsi.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/zeiss_rec_500.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/carlson_rw5.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/leica_tcr_1205.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats copying totalopenstation/formats/__init__.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/formats creating /<>/.pybuild/cpython3_3.11/build/totalopenstation/output copying totalopenstation/output/tops_sql.py -> /<>/.pybuild/cpython3_3.11/build/totalopenstation/output copying
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
reassign 1039979 debian-policy thanks Dear Policy editors: In this bug I'm asked to make /var/run and /var/lock symlinks to be relative. Maybe it's the right thing to do, but last time I tried to do that, this is what happened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345 [ Summary: I had to revert the change because it was against policy ]. So, I'm reassigning this bug to debian-policy. Please drop me a note whenever there is a consensus that relative symlinks are ok for /var/run and /var/lock (even if there is not a new policy release reflecting it yet). Thanks.
Bug#1069059: cockpit update from DSA-5655-1 without binary builds (build failures)
found 1069059 239-1 found 1069059 287-1 tags 1069059 + bullseye bookworm thanks El 15/4/24 a las 19:28, Salvatore Bonaccorso escribió: The update for cockpit in DSA 5655-1 had problems with the test-sshbridge test, causing FTBFS: For completeness: this was already happening in bullseye and bookworm before the DSA. (Reminder for myself: report all the bugs I found last week while rebuilding bullseye and bookworm). Thanks.
Bug#833319: base-files: Please package debian-swirl icon
reassign 833319 adwaita-icon-theme thanks I don't think this is appropriate for base-files. Reassigning back. Please find another package (not base-files) for that. Thanks.
Bug#1055583: base-files: EFI System Partition should mount on /efi not /boot/efi
reassign 1055583 debian-installer thanks Dear debian-installer people: In this bug report, I'm asked to provide /efi as a mount point for the EFI partition. Given that base-files does not even contain /boot/efi (the supposedly "old" location), I believe this is a decision for you to make, hence the reassign. [ I would be open to include /efi in base-files, but only if you consider necessary ]. Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
btw: /var/local is still :staff owned ... while /usr/local is no longer. Is that on purpose? Historical reasons. There was also a time in which, by default, /usr/local was also root:staff and writeable by staff. The /var/local thing is already reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039973 Thanks.
Bug#994220: base-files: add /etc/local and /usr/local/libexec
It would be nice if it could be considered to add/create: /etc/local /usr/local/libexec Thanks for the report. I'll add /usr/local/libexec as the outcome for this bug report. According to what I read, it should exist because /usr/libexec also exists. /etc/local is even kinda indirectly standardised by FHS: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html "/usr/local/etc may be a symbolic link to /etc/local." I don't think that's a mandate to provide /etc/local, because /etc/local is missing in the chapter about /etc. I see it just as a way to allow /usr/local/etc to exist as a directory or as a symlink, at your choice. Since we do not provide /etc/local, it should be ok for /usr/local/etc to remain as a directory. Thanks.
Bug#961679: base-files: please include window title in /etc/issue
El 27/5/20 a las 22:43, Adam Borowski escribió: Package: base-files Version: 11 Severity: wishlist Tags: patch Hi! It would be good if /etc/issue set the window title appropriately. While it might sound wrong (as /etc/issue is used only for local terminals), serial consoles do count as local. Thus, the output may hit either a real console which since Linux 3.16 ignores these sequences, or a terminal emulator. Hello. I don't see this very useful because normally when you have a serial console you have only one of it (so there is usually no need to differentiate between them). Simple question: I don't have a serial console myself. Is this a change for which the effects can be seen when using virtual machines in the cloud? (Let's say, Hetzner, GCP, Linode, Digital Ocean, etc). Thanks.
Bug#931197: base-files: Include minor version in /etc/os-release
severity 931197 normal thanks I consider this to be a normal bug, and will try to discuss with Release Managers to see if we can change it for trixie. Thanks.
Bug#868095: base-files: clean up legacy conffiles
Hi. I'm scared about removing /etc/profile by accident. Guillem: I see that dpkg contains some helper programs to remove "obsolete conffiles". Are they meant to be used for conffiles which should no longer exist, or also for conffiles which are no longer conffiles but should continue to exist? The end goal is to make "dpkg -s base-files" not to show /etc/profile anymore on systems which were upgraded from an old Debian release (where the file was still a conffile). Is there a tested and fool-proof way to do that? Thanks.
Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs
Hi. Let's see what we should do to remove PATH from /etc/profile. Ubuntu did that a lot of time ago and this is their changelog: base-files (3.1.9ubuntu3) dapper; urgency=low * Implement OneTruePathSpec: * share/profile: Remove PATH setting. * debian/control: Add dependency libpam-modules (>= 0.79-3ubuntu3) so that the user does not end up without any $PATH at all. So, before I go ahead, I'd like to be sure that things will not break horribly for somebody. Do we need any kind of dependency like the one on libpam-modules above? (It's no longer in their current debian/control file). Can we also drop PATH from /etc/profile in non-Linux systems like hurd-i386? (I'm Cc:ing Samuel for that). Thanks.
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
El 14/4/24 a las 13:25, Sylvestre Ledru escribió: I am sorry but I am not sure to see how it is actionable. Without a test case, i don't think there is much I can do here. The test case is that nvda2speechd fails to build from source. With rust, cargo, custom build script, there are many things that can go wrong before LLVM. Sebastian, I think it could be move to normal. From LLVM perspective, it isn't serious severity (many programs are built with LLVM 16). We can release trixie with compilers having bugs, but I don't think it would be ok at all to release trixie as stable with packages which do not build from source, that would be against Release Policy. So, in my opinion, this is still RC, either in the compiler or in the package failing to build. If solving this in the compiler is too complex, then the bug should be reassigned back to src:nvda2speechd. Thanks.
Bug#1068935: debootstrap: Creating buildd chroots of trixie/sid from bookworm
Package: src:debootstrap Version: 1.0.128+nmu2+deb12u1 Dear maintainer: Please make debootstrap in bookworm to follow the same rules as debootstrap in trixie/sid when creating a buildd chroot of trixie/sid (i.e. install only build-essential packages). Rationale and full explanation here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060#134 Thanks.
Bug#1068757: python-musicpd: FTBFS: dh_installchangelogs: error: could not find changelog
Package: src:python-musicpd Version: 0.8.0-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --with python3,sphinxdoc --buildsystem=pybuild --name=musicpd dh_update_autotools_config -O--buildsystem=pybuild -O--name=musicpd dh_autoreconf -O--buildsystem=pybuild -O--name=musicpd dh_auto_configure -O--buildsystem=pybuild -O--name=musicpd I: pybuild base:311: python3.11 setup.py config /usr/lib/python3/dist-packages/setuptools/config/setupcfg.py:293: _DeprecatedConfig: Deprecated config in `setup.cfg` !! The license_file parameter is deprecated, use license_files instead. This deprecation is overdue, please update your project and remove deprecated calls to avoid build errors in the future. See https://setuptools.pypa.io/en/latest/userguide/declarative_config.html for details. !! parsed = self.parsers.get(option_name, lambda x: x)(value) running config dh_auto_build -O--buildsystem=pybuild -O--name=musicpd I: pybuild base:311: /usr/bin/python3 setup.py build /usr/lib/python3/dist-packages/setuptools/config/setupcfg.py:293: _DeprecatedConfig: Deprecated config in `setup.cfg` !! The license_file parameter is deprecated, use license_files instead. This deprecation is overdue, please update your project and remove deprecated calls to avoid build errors in the future. See https://setuptools.pypa.io/en/latest/userguide/declarative_config.html for details. !! parsed = self.parsers.get(option_name, lambda x: x)(value) running build running build_py copying musicpd.py -> /<>/.pybuild/cpython3_3.11/build dh_auto_test -O--buildsystem=pybuild -O--name=musicpd I: pybuild base:311: cd /<>/.pybuild/cpython3_3.11/build; python3.11 -m unittest discover -v -- Ran 0 tests in 0.000s OK create-stamp debian/debhelper-build-stamp dh_testroot -O--buildsystem=pybuild -O--name=musicpd dh_prep -O--buildsystem=pybuild -O--name=musicpd dh_auto_install --destdir=debian/python3-musicpd/ -O--buildsystem=pybuild -O--name=musicpd I: pybuild base:311: /usr/bin/python3 setup.py install --root /<>/debian/python3-musicpd /usr/lib/python3/dist-packages/setuptools/config/setupcfg.py:293: _DeprecatedConfig: Deprecated config in `setup.cfg` !! The license_file parameter is deprecated, use license_files instead. This deprecation is overdue, please update your project and remove deprecated calls to avoid build errors in the future. See https://setuptools.pypa.io/en/latest/userguide/declarative_config.html for details. !! parsed = self.parsers.get(option_name, lambda x: x)(value) running install /usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated. !! Please avoid running ``setup.py`` directly. Instead, use pypa/build, pypa/installer or other standards-based tools. See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details. !! self.initialize_options() running build running build_py running install_lib creating /<>/debian/python3-musicpd/usr creating /<>/debian/python3-musicpd/usr/lib creating /<>/debian/python3-musicpd/usr/lib/python3.11 creating /<>/debian/python3-musicpd/usr/lib/python3.11/dist-packages copying /<>/.pybuild/cpython3_3.11/build/musicpd.py -> /<>/debian/python3-musicpd/usr/lib/python3.11/dist-packages byte-compiling /<>/debian/python3-musicpd/usr/lib/python3.11/dist-packages/musicpd.py to musicpd.cpython-311.pyc running install_egg_info running egg_info creating python_musicpd.egg-info writing python_musicpd.egg-info/PKG-INFO writing dependency_links to python_musicpd.egg-info/dependency_links.txt writing top-level names to python_musicpd.egg-info/top_level.txt writing manifest file 'python_musicpd.egg-info/SOURCES.txt' reading manifest file 'python_musicpd.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' adding license file 'LICENSE.txt' writing manifest file
Bug#1068754: circe: FTBFS: failing tests
Package: src:circe Version: 2.12-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules build dh build --with elpa dh_update_autotools_config dh_autoreconf debian/rules override_dh_auto_build make[1]: Entering directory '/<>' skipping upstream build make[1]: Leaving directory '/<>' dh_elpa_test buttercup -L . Loading /etc/emacs/site-start.d/00debian.el (source)... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Running 214 specs. Circe chat mode creation function should have circe-server-buffer set in the mode hook [32mshould have circe-server-buffer set in the mode hook[0m (1.93ms) The `circe-version' command should display the current version [32m should display the current version[0m (0.07ms) The `circe-duration-string' function should handle very short amounts of time [32m should handle very short amounts of time[0m (0.11ms) should support second granularity [32m should support second granularity[0m (0.17ms) should support minute granularity [32m should support minute granularity[0m (0.25ms) should support monthly granularity [32m should support monthly granularity[0m (0.11ms) Circe's completion facility should complete nicks with colon at the beginning of the input [32m should complete nicks with colon at the beginning of the input[0m (10.16ms) should complete nicks without colon later in the input [32m should complete nicks without colon later in the input[0m (8.96ms) Display of RPL_WHOISREPLY should show idle time [32mshould show idle time[0m (0.15ms) should show idle time and signon time [32mshould show idle time and signon time[0m (0.18ms) RPL_TOPICWHOTIME should show current topic time [32mshould show current topic time[0m (0.19ms) should show current topic time in a different channel [32mshould show current topic time in a different channel[0m (0.20ms) CTCP ACTION should show a query in a query buffer [32mshould show a query in a query buffer[0m (0.12ms) should show a query in the current buffer [32mshould show a query in the current buffer[0m (0.12ms) should show a channel action [32mshould show a channel action[0m (0.12ms) CTCP PING should display unknown seconds when passed nil for text [32mshould display unknown seconds when passed nil for text[0m (0.15ms) The `irc-connect' function should return a process when using non-tls connections [32m should return a process when using non-tls connections[0m (0.12ms) should return a process when using tls connections [32m should return a process when using tls connections[0m (0.43ms) should not use nowait if it is not supported [32m should not use nowait if it is not supported[0m (0.21ms) should call the sentinel if nowait is not supported [32m should call the sentinel if nowait is not supported[0m (0.08ms) Connection options should retrieve options set [32m should retrieve options set[0m (0.34ms) The `irc--sentinel' function should emit conn.failed for a failed event [32m should emit conn.failed for a failed event[0m (0.12ms) should emit conn.connected on an open event [32m should emit conn.connected on an open event[0m (0.08ms) should emit conn.disconnected for a broken connection [32m should emit conn.disconnected for a broken connection[0m (0.08ms) should emit conn.disconnected for a finished process [32m should emit conn.disconnected for a finished process[0m (0.07ms) should emit conn.disconnected for an exiting process [32m should emit conn.disconnected for an exiting process[0m (0.07ms) should ignored killed processes [32m should ignored killed processes[0m (0.06ms) should ignore deleted processes [32m should ignore deleted processes[0m (0.06ms) should raise an error for unknown events [32m should raise an error for unknown events[0m (0.09ms) The `irc--filter' function should handle single lines [32m should handle single lines[0m (0.31ms) should handle single lines even without CR [32m should handle single lines even without CR[0m (0.31ms) should handle multiple lines at once [32m should handle multiple lines at once[0m (0.36ms) should handle partial lines [32m should handle partial lines[0m (0.35ms) should not handle a line received while others are processed [32m should not handle a line received while others are processed[0m (0.37ms) The `irc--handle-line' function should emit an event for the command [32m should emit an event for the command[0m (0.15ms) The `irc--parse' function should parse a command without anything else [32m should parse a command without anything else[0m (0.11ms) should parse a command with a single argument [32m should parse a command with a single argument[0m (0.10ms)
Bug#1068750: moment-timezone.js: FTBFS everywhere
Package: src:moment-timezone.js Version: 0.5.32+dfsg1-2+2021a Severity: serious Tags: bullseye bookworm trixie sid ftbfs Dear maintainer: This package currently fails to build from source in all supported distributions. make[1]: Leaving directory '/<>' dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf debian/rules execute_before_dh_auto_configure make[1]: Entering directory '/<>' # Fail the build if the tzdata package does not match TZVER. grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:24: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 See also: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/moment-timezone.js.html I'm curious: Does this package embed the information from tzdata into javascript code, in such a way that a change in tzdata requires a rebuild? I think it would be highly desirable to find a way for this package to do what it's supposed to do without having to fix it in oldstable and stable every year. (In fact, I asked Paul Gevers about this, he says that a package which we know for sure that it will fail to build during the support time of the release is RC). Thanks.
Bug#1068654: bookworm-pu: package bioawk/1.0-4+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: bio...@packages.debian.org, sanv...@debian.org Control: affects -1 + src:bioawk [ Reason ] Fix random FTBFS bug (#1068341). [ Impact ] Any user who tries to build from source using more than one CPU may find that the package unexpectedly FTBFS in a random way. [ Tests ] I've built the package in unstable a lot of times, and it does no longer FTBFS randomly. [ Risks ] Very low, given that the fix is to add --no-parallel to dh invocation. [ 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 (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Add --no-parallel to dh invocation. [ Other info ] I'm going to make the upload now, but will wait for confirmation before pushing to salsa.diff -Nru bioawk-1.0/debian/changelog bioawk-1.0/debian/changelog --- bioawk-1.0/debian/changelog 2021-03-17 17:53:42.0 +0100 +++ bioawk-1.0/debian/changelog 2024-04-08 19:40:00.0 +0200 @@ -1,3 +1,11 @@ +bioawk (1.0-4+deb12u1) bookworm; urgency=medium + + * Team upload. + * debian/rules: Add --no-parallel to avoid the effects of a Makefile bug which +makes the package to FTBFS randomly. Closes: #1068341. + + -- Santiago Vila Mon, 08 Apr 2024 19:40:00 +0200 + bioawk (1.0-4) unstable; urgency=medium * d/p/cross.patch: Fix non-cross buildability diff -Nru bioawk-1.0/debian/rules bioawk-1.0/debian/rules --- bioawk-1.0/debian/rules 2021-03-17 17:53:42.0 +0100 +++ bioawk-1.0/debian/rules 2024-04-08 19:39:55.0 +0200 @@ -5,7 +5,7 @@ include /usr/share/dpkg/buildtools.mk %: - dh $@ + dh $@ --no-parallel override_dh_auto_configure:
Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a
Just for the record: I finally used this, in line with the original proposal: Replaces: dialog (<< 1.3-20240307-1~) Breaks: dialog (<< 1.3-20240307-1~) Thanks.
Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a
Ok. This is a little bit subtle. I naively tried to simplify the fields by using this: Replaces: dialog (<< 1.3-20240307) Breaks: dialog (<< 1.3-20240307) But this actually means upstream version 1.3, debian revision 20240307, not upstream 1.3-20240307. I guess I should use 1.3-20240307-0 at minimum. Thanks.
Bug#1068634: libdialog-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libdialog.a
El 8/4/24 a las 9:18, Helmut Grohne escribió: Package: libdialog-dev Version: 1.3-20240307-1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + dialog libdialog-dev has an undeclared file conflict. This may result in an unpack error from dpkg. The file /usr/lib/x86_64-linux-gnu/libdialog.a is contained in the packages * dialog * 1.3-20201126-1 as present in bullseye * 1.3-20230209-1 as present in bookworm * 1.3-20240101-1 as present in trixie * libdialog-dev/1.3-20240307-1 as present in unstable These packages can be unpacked concurrently, because there is no relevant Replaces or Conflicts relation. Thanks for the report. libdialog-dev has: Replaces: dialog (<< 1.3-20240307) Breaks: dialog (<< 1.3-20240307) Is this really not enough? Is Policy up to date regarding this? (Cc: Sven, who was helping with the package split). Thanks.
Bug#1024532: gjs allocates 237 GB of RAM during build (!)
tags 1024532 - moreinfo close 1024532 1.79.3-1 thanks I can verify that the version currently in trixie does not show this behaviour anymore (maximum allocated memory is now below 1 GB). Therefore I'm closing this bug myself. (It would have been interesting maybe to know in which version it was fixed and how, but I'll leave that to bug archeologists). Thanks.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Hi. I have made the upload. But now I remember that this may get rejected for requiring new binary packages (not sure if this has changed since the last time), so wish me luck... Thanks a lot for all the help!
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
El 6/4/24 a las 20:53, Sven Joachim escribió: 1. https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 Ok, I had not read that part of Policy in a long time. One minor last thing: Assuming I make the changes and package the new available upstream version at the same time, can I simplify the breaks and replaces to just "(<< 1.3-20240307)"? Thanks.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
Patch attached, I have tested that it builds on amd64 and i386. looked at the generated Dependencies and verified that lintian does not go crazy, but that's it. Note that I had to add libtool-bin rather than just libtool to Build-Depends to prevent configure from complaining, and also pacify dh_missing considering the not installed .la file. Awesome, thanks a lot! Regarding the static library, I can see now that keeping it does not really make the package more complex, so we'll keep it. A few questions: - Does this require a "transition"? I think not, because the API has not changed. On the other hand, packages which build-depend on libdialog-dev should be rebuilt with the shared library anyway, and this is usually done as part of a transition. - Regarding the Breaks field, I think it's not actually required and we should not add it (i.e. Replaces is enough). I tried creating the packages without the Breaks field, installing the libdialog and libdialog-dev packages on a system where dialog was already installed, and this is what happened: # dpkg -i libdialog-dev_1.3-20240101-2_amd64.deb libdialog15_1.3-20240101-2_amd64.deb (Reading database ... 14174 files and directories currently installed.) Preparing to unpack libdialog-dev_1.3-20240101-2_amd64.deb ... Unpacking libdialog-dev:amd64 (1.3-20240101-2) ... Replacing files in old package dialog (1.3-20240101-1) ... Preparing to unpack libdialog15_1.3-20240101-2_amd64.deb ... Unpacking libdialog15:amd64 (1.3-20240101-2) over (1.3-20240101-2) ... Setting up libdialog15:amd64 (1.3-20240101-2) ... Setting up libdialog-dev:amd64 (1.3-20240101-2) ... Processing triggers for man-db (2.12.1-1) ... Not building database; man-db/auto-update is not 'true'. Processing triggers for libc-bin (2.37-15.1) ... i.e. no errors, dpkg takes note of the moved files, and the old dialog is still functional, because it's still linked statically. Thanks.
Bug#1060939: python-workalendar: FTBFS because of failing tests
forwarded 1060939 https://github.com/workalendar/workalendar/issues/764 tags 1060939 + bookworm thanks
Bug#1068497: golang-github-antonini-golibjpegturbo: FTBFS: Tries to access the network during build
Package: src:golang-github-antonini-golibjpegturbo Version: 0.0~git20141208.c03a2fa-2 Severity: serious Tags: ftbfs [...] github.com/antonini/golibjpegturbo dh_auto_test -O--builddirectory=_build -O--buildsystem=golang cd _build && go test -vet=off -v -p 20 github.com/antonini/golibjpegturbo panic: Get "https://farm1.staticflickr.com/47/139138903_3d9600174d_b_d.jpg": dial tcp: lookup farm1.staticflickr.com on [::1]:53: read udp [::1]:40015->[::1]:53: read: connection refused https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-antonini-golibjpegturbo.html
Bug#1053334: galera-4: FTBFS because of expired certificates
El 23/12/23 a las 3:07, Otto Kekäläinen escribió: Sure, this will be fixed (automatically) with uploading latest upstream minor release as stable update, and I intend to do it in coming 1-2 weeks. Hi. Can you elaborate on that? Release managers do not usually allow new upstream releases in stable. Is this something for which you have already an ok from them? I'm trying to ensure that all packages in stable build from source in stable, so this kind of "will be fixed eventually" is not good enough in my opinion. Thanks.
Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)
El 4/4/24 a las 19:44, Johannes Schauer Marin Rodrigues escribió: instead of doing that, you could've worked around this by just placing the build log into a dedicated temporary directory and then copying it to where you want it after the build is finished. That would be an option, yes, but maybe it's too convoluted for my taste. Can you give me a small hint about how I should proceed? (For example, which files in the source would require to be modified?) (Preferred name for the command line?) An example commit that adds a new option would be a44b29e76450ce8c80467e0957ebc6909167e425 by Jochen. You need to touch these files: - lib/Sbuild/Build.pm to implement the thing - lib/Sbuild/Conf.pm to add the configuration option - lib/Sbuild/Options.pm to add the command line argument changing the config option - man/sbuild.1.in to document the command line argument Thanks a lot! I'll try that. I think I'd find an option useful which allows to pass a completely custom build log filename. There is already the LOG_DIR configuration variable. Maybe add the LOG_FILENAME configuration variable containing the filename that the log will have when placed in LOG_DIR. The command line option can be named --log-filename accordingly. But I only need the date part. I still want sbuild to take care of the filename, just not of the timestamp part of the filename. I'll take a look at your hints above and see what I can do. Don't run sbuild in the future. Only run dpkg inside sbuild in the future. This is what the BUILD_ENV_CMND option lets you do. From the man page: This command is run with the dpkg-buildpackage command line passed to it (in the chroot, if doing a chrooted build). It is used by the sparc buildd (which is sparc64) to call the wrapper script that sets the environment to sparc (32-bit). It could be used for other build environment setup scripts. I'm not sure that running only dpkg in the future is what I want to do. I want to recreate the experience of building in the future as faithfully as possible, so I believe setting the system clock still makes sense. If you run sbuild with a fake time, you also run apt with a fake time which means you potentially get into trouble with https mirrors and their certificate expiration times, for example. I know, but that would violate the principle of desert island for QA, which I formulate as follows: "It must be possible to build all packages in stable several years after the release without having to update any of them". or in other words: "Packages in stable must not contain time bombs preventing their succesful build in the few years which follow the release of stable" In practice I already found the expiration problem for the release files that you mention, so I already know how far in the future I can go. My plan is to ask RMs to consider RC any FTBFS bug which happens not just the day before we release trixie as stable (which is what we did for bookworm) but also some years ahead (for example, maybe two for stable, two for oldstable, and one more for general LTS). Thanks.
Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode
El 4/4/24 a las 19:29, Johannes Schauer Marin Rodrigues escribió: Also I'm curious: what is your motivation for using unshare mode if you are creating your chroots using superuser privileges? And are you really storing your chroots in /srv instead of letting them get picked up automatically in ~/.cache/sbuild/unstable-arm64.tar? I am testing the unshare backend at the request of Jochen. As we speak, I am building all packages in bookworm using unshare. I already had a working setup for building packages using the other backends. In my setup, I run debootstrap in a master server, create the tarballs there, and the build nodes retrieve those tarballs using wget before they start to build packages. So in my setup the logical thing to do to test the unshare backend was to make symlinks to the already existing tarballs at /srv, since the nodes are not creating any tarballs. Thanks.
Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists
Nilesh: Would it help if I do a "team upload" to fix this? (Using the proposed patch) Or would you prefer to fix it yourself? Just go ahead with a fix. I don't have much time these days. Please also drop me from uploaders field for this package won't have time to maintain this. Yes, I noticed, as there was already a commit in git about that. I've made the commits in salsa and the upload. Thanks a lot.
Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode
El 4/4/24 a las 14:22, Johannes Schauer Marin Rodrigues escribió: Since I don't think a tarball without ./ is really "wrong" to the point that it needs to be recreated (this is in fact the very first in my life that a tarball without ./ causes any kind of trouble), I think it would be desirable to support those tarballs as well. how did you create that tarball? debootstrap to a directory cd /chroot/directory tar czvf /srv/whatever.tar.gz * Yes, I know what using "." instead of "*" would solve the problem, but as I said, sbuild already supports perfectly tarballs without ./ in the "file" backend, so the consistent thing would be to support them for unshare as well. So, we (Jochen and myself) wonder if any of the following patches would be acceptable to you. The first patch adds --anchored option to tar invocation so that the exclude patterns are matched from the beginning only (not anywhere in the filename), then adds the remaining eight exclude patterns for tarballs without "./". I could agree that the end result is not very nice, but it's simple, effective, and imo it's not really so much ugly. However, while we are at it, I wonder why it's necessary to uncompress anything in /dev at all these days. Would it work if everything in /dev is excluded? The second patch (untested) supports tarballs with or without ./ and at the same time simplifies the exclude patterns to just two. Your addition of --anchored drops support for tarballs with members that start with ././ or with ./././ and so on. Yes, but those tarballs are a lot more uncommon, so if we had to choose between supporting "" and "./" or supporting "./" and "././" and "./././" etc, I guess supporting "" and "./" would be preferred. So, well spotted, but I don't think that dropping support for ././ would be a big deal. Your second patch is described as "Do not extract anything in /dev" but what it actually excludes is the directory itself and not just everything in it. That's why I said "untested" :-) The point was to convey the idea, not the implementation. Maybe a better solution would be to pipe the tarballs through mmtarfilter and just remove all the device nodes from them. This avoids requiring any --exclude options for tar. Hmm, but if we get to such point, maybe we should really advocate for debootstrap and friends to stop including any /dev/* files at all. Thanks.
Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)
El 4/4/24 a las 14:07, Johannes Schauer Marin Rodrigues escribió: well this is an old bug. How have you worked around it being open for the past six years? This is important for me, so I'm still patching my own sbuild version. Yes, every single time. Quoting Santiago Vila (2024-04-04 12:57:13) I'm not happy with using an environment variable for this. Sbuild only has a single environment variable that is specific to it: SBUILD_CONFIG. The usual way to customize an sbuild run is via the config or command line arguments, not via environment variables. Also, your patch is missing documentation. Ok. At the time, I was completely unaware of such design decisions, so an environment variable is just the way I found to be simpler, but a command line argument would be completely fine of course. Can you give me a small hint about how I should proceed? (For example, which files in the source would require to be modified?) (Preferred name for the command line?) I also think that there is a more elegant solution to this. If this is just about the timestamp, why not add a new configuration option which allows customizing the default strftime format %FT%TZ to be anything else? You could use such a mechanism to store your own timestamp. This is what you suggested doing earlier in this bug report. Unfortunately, it's not just about the date format (that's only how it started), it's mainly about sbuild allowing me to specify the build log filename beforehand, without it second-guessing the string I really want to use. I have a recent case where the usefulness of this may be seen easily: Last time I tried to rebuild bookworm from source, I found several packages which FTBFS because of expired SSL certificates being used in the tests. So I decided to build bookworm "in the future" to know which packages will fail for similar reasons in the next years. I first tried using libfaketime but did not managed for it to work easily. At the end, the most reliable way I found was to actually change the system clock, like this: timedatectl set-time '2031-01-14 12:00:00' Now, here is the thing: When I do that, sbuild would think (rightfully) that I'm on such date, and would use it for both the contents of the build log and also the build log filename. However, in this case I still want the build log filename to be the present day, because it's the real date where I tried such build in the future. Thanks.
Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)
tags 834736 + patch
thanks
Hello.
I've simplified the proposed patch to the one in the attach,
and now it is probably as small as it can be without losing
readability (two lines).
It works for me, I have been using it for eight years now, and it's
still my preferred way to tell sbuild the filename that I want to use
for the build log.
[ If the environment variable name is not good enough, just use one
which makes sense. I will gladly adapt my scripts ]
Thanks.commit 36f4e780f4a6de6a1ebceaa4fcd6bc53fe952fcb
Author: Santiago Vila
Date: Thu Apr 4 12:30:00 2024 +0200
lib/Sbuild/Build.pm:
Allow the user to set the timestamp part of the build log filename
via SBUILD_LOG_TIMESTAMP environment variable.
If such variable exists and it's not empty, it will be used
instead of $date.
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -3270,7 +3270,8 @@ sub open_build_log {
} else {
$filename .= $self->get('Package');
}
-$filename .= '_' . $self->get('Host Arch') . "-$date";
+my $log_timestamp = $ENV{'SBUILD_LOG_TIMESTAMP'} || $date;
+$filename .= '_' . $self->get('Host Arch') . "-$log_timestamp";
$filename .= ".build" if $self->get_conf('SBUILD_MODE') ne 'buildd';
open($saved_stdout, ">") or warn "Can't redirect stdout\n";
Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode
Package: sbuild
Version: 0.85.6
Severity: wishlist
Dear maintainer:
While trying to use the unshare backend I found this error:
tar: dev/full: Cannot mknod: Operation not permitted
tar: dev/urandom: Cannot mknod: Operation not permitted
tar: dev/console: Cannot mknod: Operation not permitted
tar: dev/ptmx: Cannot mknod: Operation not permitted
tar: dev/random: Cannot mknod: Operation not permitted
[...]
The reason (as Jochen identified quickly) is that my tarball did not
include ./ entries, so the exclude patterns in lib/Sbuild/ChrootUnshare.pm
had no effect.
Since I don't think a tarball without ./ is really "wrong" to the point
that it needs to be recreated (this is in fact the very first in my life
that a tarball without ./ causes any kind of trouble), I think it would be
desirable to support those tarballs as well.
So, we (Jochen and myself) wonder if any of the following patches
would be acceptable to you.
The first patch adds --anchored option to tar invocation so that
the exclude patterns are matched from the beginning only
(not anywhere in the filename), then adds the remaining eight
exclude patterns for tarballs without "./".
I could agree that the end result is not very nice, but it's
simple, effective, and imo it's not really so much ugly.
However, while we are at it, I wonder why it's necessary to
uncompress anything in /dev at all these days. Would it work
if everything in /dev is excluded?
The second patch (untested) supports tarballs with or
without ./ and at the same time simplifies the exclude
patterns to just two.
Thanks.commit d54e3303e4a212a790f736b2b9db072c6fe7b25e
Author: Santiago Vila
Date: Thu Apr 4 11:30:00 2024 +0200
lib/Sbuild/ChrootUnshare.pm:
Use tar's --anchored option to support tarballs including ./ and also those
not including ./
diff --git a/lib/Sbuild/ChrootUnshare.pm b/lib/Sbuild/ChrootUnshare.pm
index 91a7fa43..02d80936 100644
--- a/lib/Sbuild/ChrootUnshare.pm
+++ b/lib/Sbuild/ChrootUnshare.pm
@@ -166,6 +166,15 @@ sub begin_session {
print STDOUT "Unpacking $tarball to $rootdir...\n";
@cmd = (@unshare_cmd, 'tar',
+ '--anchored',
+ '--exclude=dev/urandom',
+ '--exclude=dev/random',
+ '--exclude=dev/full',
+ '--exclude=dev/null',
+ '--exclude=dev/console',
+ '--exclude=dev/zero',
+ '--exclude=dev/tty',
+ '--exclude=dev/ptmx',
'--exclude=./dev/urandom',
'--exclude=./dev/random',
'--exclude=./dev/full',
commit 47a0ed399f17d0cfc2a5af17bccd55880e5c7892
Author: Santiago Vila
Date: Thu Apr 4 11:30:00 2024 +0200
lib/Sbuild/ChrootUnshare.pm:
Do not extract anything in /dev
Use tar's --anchored option to support tarballs including ./ and also those
not including ./
diff --git a/lib/Sbuild/ChrootUnshare.pm b/lib/Sbuild/ChrootUnshare.pm
index 91a7fa43..3e554e9c 100644
--- a/lib/Sbuild/ChrootUnshare.pm
+++ b/lib/Sbuild/ChrootUnshare.pm
@@ -166,14 +166,9 @@ sub begin_session {
print STDOUT "Unpacking $tarball to $rootdir...\n";
@cmd = (@unshare_cmd, 'tar',
- '--exclude=./dev/urandom',
- '--exclude=./dev/random',
- '--exclude=./dev/full',
- '--exclude=./dev/null',
- '--exclude=./dev/console',
- '--exclude=./dev/zero',
- '--exclude=./dev/tty',
- '--exclude=./dev/ptmx',
+ '--anchored',
+ '--exclude=dev/',
+ '--exclude=./dev/',
'--directory', $rootdir,
'--extract'
);
Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists
Hi. I've just realized that (as a member of Debian Med) I could fix this myself. Nilesh: Would it help if I do a "team upload" to fix this? (Using the proposed patch) Or would you prefer to fix it yourself? Thanks.
Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists
Package: src:bioawk Version: 1.0-4 Severity: important Tags: ftbfs patch Dear maintainer: This package fails to build from source in a random fashion due to what it seems to be a Makefile bug: This is from my own autobuilder: make[1]: Entering directory '/<>' bison -y -d awkgram.y bison -y -d awkgram.y awkgram.y: warning: 43 shift/reduce conflicts [-Wconflicts-sr] awkgram.y: warning: 85 reduce/reduce conflicts [-Wconflicts-rr] awkgram.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples awkgram.y: warning: 43 shift/reduce conflicts [-Wconflicts-sr] awkgram.y: warning: 85 reduce/reduce conflicts [-Wconflicts-rr] awkgram.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples cp y.tab.c ytab.c cp y.tab.c ytab.c cp: cannot create regular file 'ytab.c': File exists make[1]: *** [Makefile:49: ytab.h] Error 1 make[1]: *** Waiting for unfinished jobs cp y.tab.h ytab.h gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=for mat-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -c ytab.c make[1]: Leaving directory '/<>' dh_auto_build: error: make -j2 "INSTALL=install --strip-program=true" returned exit code 2 make: *** [debian/rules:8: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 This has also happened on the buildds several times: https://buildd.debian.org/status/fetch.php?pkg=bioawk=sparc64=1.0-2=1614438070=0 https://buildd.debian.org/status/fetch.php?pkg=bioawk=riscv64=1.0-2=1614441112=0 https://buildd.debian.org/status/fetch.php?pkg=bioawk=armhf=1.0-3=1614527051=0 I believe the error happens when the same target is being executed twice at the same time. Given that the package is very small and it builds in a few seconds, I suggest disabling parallel build as a simple and effective way to fix the problem. Patch attached. Thanks.--- a/debian/rules +++ b/debian/rules @@ -5,7 +5,7 @@ DPKG_EXPORT_BUILDTOOLS = nonempty include /usr/share/dpkg/buildtools.mk %: - dh $@ + dh $@ --no-parallel override_dh_auto_configure:
Bug#1028356: procmail: Variable set with stdin pipe action fails leaving empty variable
Hi. I have just reuploaded version 3.22. This is certainly not the ideal state for this ancient package, but I believe it's slightly better than keeping an important regression forever. If upstream decides to maintain procmail again (which means addressing regressions, not merely making a new release), it could make sense to consider the switch again. I was about to write all this in the Debian changelog, but this place is probably more appropriate. Thanks a lot.
Bug#1012325: dialog: Multi-Arch: foreign package should not contain static library
El 30/3/24 a las 9:43, Sven Joachim escribió: I think it would make sense for Debian to follow what Arch and Fedora are doing, introduce a libdialog15 package with the shared library and a libdialog-dev package with the .so symlink but without libdialog.a, because that requires (if I understood you correctly) configuring and building dialog twice, greatly complicating packaging. Santiago, do you think this is a good plan? Yes. If we can avoid the static library to keep it simple, that would be better. Simple question: Is that really allowed these days? I wanted to be sure by reading Policy but did not find any statement saying they are required or not. I can work on an updated patch. That would definitely help. Thanks a lot!
Bug#1064765: prometheus: FTBFS: dh_auto_test error
Version: 2.45.3+ds-3 El 28/3/24 a las 23:38, Daniel Swarbrick escribió: On 28.03.24 23:33, Santiago Vila wrote: If you prefer I could report this build failure in a new report (or you can also use the clone command so that the bug has a new number, then close the old bug). Please report a new bug, with just the relevant info regarding the new build failure. Ok, will do. Closing this one, then. We already override the default test timeout for arm, mips64el and riscv64 to 60 minutes, as well as set "-short", because otherwise those archs simply take too long to grind through all the tests. If you expect these tests to pass on a host with only one or two cores, we will certainly need to raise the test timeout, even for fast amd64 hosts. Yes, I expect it to work on all systems on which prometheus itself works. (And as a prometheus user myself, I've used it in all sort of systems, big or small). Thanks.
Bug#1064765: prometheus: FTBFS: dh_auto_test error
El 28/3/24 a las 22:42, Daniel Swarbrick escribió: I think you are taking the "FAILED" out of context and misinterpreting the test output. This is very likely, yes, and I'm sorry for that. If you prefer I could report this build failure in a new report (or you can also use the clone command so that the bug has a new number, then close the old bug). Thanks.
Bug#1064765: prometheus: FTBFS: dh_auto_test error
El 28/3/24 a las 22:42, Daniel Swarbrick escribió: Please can you find in your logs the _actual_ failing test or tests, because it is not TestRulesUnitTest. Ok, I'm attaching one of my build logs for version 2.45.3+ds-3. This one was tried on a m6a.large instance from AWS, which has 2 CPUs. Thanks. prometheus_2.45.3+ds-3_amd64-20240325T141933.921Z.gz Description: application/gzip
Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
Ok, the problem was that CFLAGS now contains -Werror=implicit-function-declaration by default, set by dpkg-buildflags in unstable. The minimal fix is to drop such option, by adding this line to debian/rules: export DEB_CFLAGS_MAINT_STRIP = -Werror=implicit-function-declaration I'm Cc:ing Andrey Rakhmatullin, who was kind enough to look at this and try to diagnose it. Thanks.
Bug#1064765: prometheus: FTBFS: dh_auto_test error
found 1064765 2.45.3+ds-3 thanks Daniel Swarbrick wrote: * Add new 0022-Support-prometheus-common-0.47.0.patch (Closes: #1064765) Hello. I don't quite understand how the above fix is related to the bug itself (but maybe it's because I don't know prometheus internals). In either case, this is still happening for me in the current version: Lucas Nussbaum wrote: FAILED: 1:48: parse error: unexpected character inside braces: '0' Note: I'm currently using virtual machines with 1 CPU and with 2 CPUs for archive rebuilds. On systems with 2 CPUs, the package FTBFS randomly. On systems with 1 CPU, the package FTBFS always. Therefore, to reproduce, please try GRUB_CMDLINE_LINUX="nr_cpus=1" in /etc/default/grub first. If that's still not enough to reproduce the build failure, please contact me privately and I will gladly provide a machine to reproduce it. Thanks.
Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
I saw this go past, and it seemed that the solution was indeed just to #include ; are you saying it's more complicated than that? It depends on how much good we want the fix to be. I started to add such includes every time the C compiler suggested it. When I had already a bunch of them, I realized there is a macro STDC_HEADERS which is not properly detected. That seems the proper solution. So, I tried to override such variable but didn't find the way. Now my current idea is to change the code in this way wherever needed: -#if STDC_HEADERS +#if STDC_HEADERS || 1 Will tell you how it goes. That would be the easy fix. For a more proper fix, I'd like to know why STDC_HEADERS is not properly detected, but I don't know enough autoconf to debug that. Thanks.
Bug#1017144: gammaray: FTBFS: test failed
severity 1017144 serious thanks El 30/4/23 a las 19:10, Dmitry Shachnev escribió: Injector error: Process crashed I acknowledge that a few tests are flaky, but it does not mean that this package fails to build completely. Since this bug was filed on 2022-08-14, it built successfully on amd64 buildds on 2022-10-01, 2022-12-21, 2022-12-24, 2023-01-15 and 2023-03-02. I see that you skipped the dates where the build failed, also from amd64 buildds: 2022-12-24 17:29:27 2022-12-24 19:06:34 2023-01-15 14:20:23 2023-03-02 18:45:35 So, it might not fail to build all the time, but the failure rate is around 50%, which is way above what is normally considered acceptable for a stable release. The tests which seem to fail over and over again are these two: 2 - connectiontest-preload-filter (Failed) 4 - connectiontest-style-filter (Failed) If you wish to debug those flaky tests, I can offer a virtual machine for you for that where the package FTBFS as much as 50% of the time (contact me privately for details). If you don't have time or motivation to investigate, no problem, but in such case please disable the flaky tests (or just mark them as a flaky if the test framework allows it) so that the package may be built without failures. Thanks.
Bug#1066203: Fwd: Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]
Hello. I've received this report from the Debian BTS. Have not had time to look at it. I guess I need help. Thanks. Mensaje reenviado Asunto: Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration] Resent-Date: Wed, 13 Mar 2024 11:51:31 + Resent-From: Lucas Nussbaum Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Santiago Vila Fecha: Wed, 13 Mar 2024 12:44:18 +0100 De: Lucas Nussbaum Responder a: Lucas Nussbaum , 1066...@bugs.debian.org Para: sub...@bugs.debian.org Source: recode Version: 3.6-25 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef Hi, During a rebuild of all packages in sid, your package failed to build on amd64. This is most likely caused by a change in dpkg 1.22.6, that enabled -Werror=implicit-function-declaration. For more information, see https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration Relevant part (hopefully): gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c realloc.c error.c: In function ‘error_at_line’: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration] 197 | (file_name == old_file_name || !strcmp (old_file_name, file_name))) | ^~ error.c:51:1: note: include ‘’ or provide a declaration of ‘strcmp’ 50 | #include "error.h" +++ |+#include 51 | realloc.c:28:7: warning: conflicting types for built-in function ‘realloc’; expected ‘void *(void *, long unsigned int)’ [-Wbuiltin-declaration-mismatch] 28 | char *realloc (); | ^~~ realloc.c:26:1: note: ‘realloc’ is declared in header ‘’ 25 | #include +++ |+#include 26 | malloc.c:27:7: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long unsigned int)’ [-Wbuiltin-declaration-mismatch] 27 | char *malloc (); | ^~ malloc.c:26:1: note: ‘malloc’ is declared in header ‘’ 25 | #include +++ |+#include 26 | cc1: some warnings being treated as errors make[4]: *** [Makefile:172: error.o] Error 1 The full build log is available from: http://qa-logs.debian.net/2024/03/13/recode_3.6-25_unstable.log All bugs filed during this archive rebuild are listed at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org or: https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please mark it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with mine so that we can identify if something relevant changed in the meantime.
Bug#1067798: python-pykmip: FTBFS: failing tests
Package: src:python-pykmip Version: 0.10.0-6 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules build make: pyversions: No such file or directory py3versions: no X-Python3-Version in control file, using supported versions dh build --buildsystem=python_distutils --with python3 dh_update_autotools_config -O--buildsystem=python_distutils dh_autoreconf -O--buildsystem=python_distutils dh_auto_configure -O--buildsystem=python_distutils dh_auto_configure: warning: Please use the third-party "pybuild" build system instead of python-distutils dh_auto_configure: warning: This feature will be removed in compat 12. debian/rules override_dh_auto_build make[1]: Entering directory '/<>' make[1]: pyversions: No such file or directory py3versions: no X-Python3-Version in control file, using supported versions echo "Do nothing..." Do nothing... make[1]: Leaving directory '/<>' debian/rules override_dh_auto_test make[1]: Entering directory '/<>' make[1]: pyversions: No such file or directory py3versions: no X-Python3-Version in control file, using supported versions set -e ; for i in 3.12 3.11 ; do \ PYTHONPATH=. PYTHON=python$i python$i -m coverage run --source=kmip/ -m pytest --strict kmip/tests/unit ; \ done = test session starts == platform linux -- Python 3.12.2, pytest-8.1.1, pluggy-1.4.0 rootdir: /<> configfile: pytest.ini collected 3394 items kmip/tests/unit/core/attributes/test_application_specific_information.py . [ 0%] .. [ 0%] kmip/tests/unit/core/attributes/test_attributes.py ......... [ 1%] [ 3%] [ 3%] kmip/tests/unit/core/attributes/test_digest.py [ 4%] kmip/tests/unit/core/factories/payloads/test_payload.py [ 4%] ... [ 5%] kmip/tests/unit/core/factories/payloads/test_request.py [ 6%] .. [ 6%] kmip/tests/unit/core/factories/payloads/test_response.py ... [ 7%] ... [ 8%] kmip/tests/unit/core/factories/test_attribute.py . [ 8%] kmip/tests/unit/core/factories/test_attribute_values.py ..ss.s.s [ 8%] s[ 9%] kmip/tests/unit/core/messages/contents/test_authentication.py .. [ 9%] .. [ 9%] kmip/tests/unit/core/messages/contents/test_protocol_version.py [ 10%] .[ 10%] kmip/tests/unit/core/messages/payloads/test_activate.py .. [ 11%] kmip/tests/unit/core/messages/payloads/test_archive.py . [ 11%] .[ 11%] kmip/tests/unit/core/messages/payloads/test_cancel.py .. [ 12%] ... [ 12%] kmip/tests/unit/core/messages/payloads/test_check.py ... [ 13%] .[ 14%] kmip/tests/unit/core/messages/payloads/test_create.py .. [ 14%] [ 15%] kmip/tests/unit/core/messages/payloads/test_create_key_pair.py . [ 16%] ... [ 17%] kmip/tests/unit/core/messages/payloads/test_decrypt.py . [ 18%] .[ 19%] kmip/tests/unit/core/messages/payloads/test_delete_attribute.py [ 19%] .[ 20%] kmip/tests/unit/core/messages/payloads/test_derive_key.py .. [ 20%] ... [ 22%] kmip/tests/unit/core/messages/payloads/test_discover_versions.py ... [ 22%] .[ 22%] kmip/tests/unit/core/messages/payloads/test_encrypt.py . [ 23%] .. [ 24%] kmip/tests/unit/core/messages/payloads/test_get.py . [ 25%] .. [ 26%]
Bug#1067794: flask-login: FTBFS: failing tests
Package: src:flask-login Version: 0.6.3-1 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild dh_auto_build -O--buildsystem=pybuild I: pybuild plugin_pyproject:129: Building wheel for python3.12 with "build" module I: pybuild base:305: python3.12 -m build --skip-dependency-check --no-isolation --wheel --outdir /<>/.pybuild/cpython3_3.12_flask-login * Building wheel... running bdist_wheel running build running build_py creating build creating build/lib creating build/lib/flask_login copying src/flask_login/__about__.py -> build/lib/flask_login copying src/flask_login/test_client.py -> build/lib/flask_login copying src/flask_login/login_manager.py -> build/lib/flask_login copying src/flask_login/mixins.py -> build/lib/flask_login copying src/flask_login/utils.py -> build/lib/flask_login copying src/flask_login/signals.py -> build/lib/flask_login copying src/flask_login/__init__.py -> build/lib/flask_login copying src/flask_login/config.py -> build/lib/flask_login running egg_info creating src/Flask_Login.egg-info writing src/Flask_Login.egg-info/PKG-INFO writing dependency_links to src/Flask_Login.egg-info/dependency_links.txt writing requirements to src/Flask_Login.egg-info/requires.txt writing top-level names to src/Flask_Login.egg-info/top_level.txt writing manifest file 'src/Flask_Login.egg-info/SOURCES.txt' reading manifest file 'src/Flask_Login.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' no previously-included directories found matching 'docs/_build' warning: no previously-included files matching '*.pyc' found anywhere in distribution adding license file 'LICENSE' writing manifest file 'src/Flask_Login.egg-info/SOURCES.txt' installing to build/bdist.linux-x86_64/wheel running install running install_lib creating build/bdist.linux-x86_64 creating build/bdist.linux-x86_64/wheel creating build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/__about__.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/test_client.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/login_manager.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/mixins.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/utils.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/signals.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/__init__.py -> build/bdist.linux-x86_64/wheel/flask_login copying build/lib/flask_login/config.py -> build/bdist.linux-x86_64/wheel/flask_login running install_egg_info Copying src/Flask_Login.egg-info to build/bdist.linux-x86_64/wheel/Flask_Login-0.6.3.egg-info running install_scripts creating build/bdist.linux-x86_64/wheel/Flask_Login-0.6.3.dist-info/WHEEL creating '/<>/.pybuild/cpython3_3.12_flask-login/.tmp-ouobfdbj/Flask_Login-0.6.3-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it adding 'flask_login/__about__.py' adding 'flask_login/__init__.py' adding 'flask_login/config.py' adding 'flask_login/login_manager.py' adding 'flask_login/mixins.py' adding 'flask_login/signals.py' adding 'flask_login/test_client.py' adding 'flask_login/utils.py' adding 'Flask_Login-0.6.3.dist-info/LICENSE' adding 'Flask_Login-0.6.3.dist-info/METADATA' adding 'Flask_Login-0.6.3.dist-info/WHEEL' adding 'Flask_Login-0.6.3.dist-info/top_level.txt' adding 'Flask_Login-0.6.3.dist-info/RECORD' removing build/bdist.linux-x86_64/wheel Successfully built Flask_Login-0.6.3-py3-none-any.whl I: pybuild plugin_pyproject:144: Unpacking wheel built for python3.12 with "installer" module I: pybuild plugin_pyproject:129: Building wheel for python3.11 with "build" module I: pybuild base:305: python3.11 -m build --skip-dependency-check --no-isolation --wheel --outdir /<>/.pybuild/cpython3_3.11_flask-login * Building wheel... running bdist_wheel running build running build_py running egg_info writing src/Flask_Login.egg-info/PKG-INFO writing dependency_links to src/Flask_Login.egg-info/dependency_links.txt writing requirements to src/Flask_Login.egg-info/requires.txt writing top-level names to src/Flask_Login.egg-info/top_level.txt reading manifest file 'src/Flask_Login.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' no previously-included directories found matching 'docs/_build' warning: no previously-included files matching '*.pyc' found anywhere in distribution adding license file 'LICENSE' writing manifest file 'src/Flask_Login.egg-info/SOURCES.txt' installing to build/bdist.linux-x86_64/wheel running install running install_lib creating
Bug#1067797: node-y-protocols: FTBFS: error TS2307: Cannot find module 'undici-types' or its corresponding type declarations.
Package: src:node-y-protocols Version: 1.0.5-7 Severity: serious Tags: ftbfs Dear maintainer: During a rebuild of all packages in unstable, your package failed to build: [...] debian/rules binary dh binary --with nodejs --buildsystem=nodejs dh_update_autotools_config -O--buildsystem=nodejs dh_autoreconf -O--buildsystem=nodejs dh_auto_configure --buildsystem=nodejs -O--buildsystem=nodejs Link ./node_modules/@rollup/plugin-commonjs -> /usr/share/nodejs/@rollup/plugin-commonjs Link ./node_modules/@rollup/plugin-node-resolve -> /usr/share/nodejs/@rollup/plugin-node-resolve Copy /usr/share/nodejs/lib0 -> ./node_modules/ cp: cannot overwrite non-directory './node_modules/@rollup/plugin-node-resolve' with directory '/usr/share/nodejs/@rollup/plugin-node-resolve' Copy /usr/share/nodejs/@rollup/plugin-node-resolve -> ./node_modules/@rollup Copy /usr/share/nodejs/@rollup/pluginutils -> ./node_modules/@rollup Copy /usr/share/nodejs/rollup -> ./node_modules/ cp: cannot overwrite non-directory './node_modules/@rollup/plugin-commonjs' with directory '/usr/share/nodejs/@rollup/plugin-commonjs' Copy /usr/share/nodejs/@rollup/plugin-commonjs -> ./node_modules/@rollup Copy /usr/share/nodejs/@types/node -> ./node_modules/@types Not found ### @types/undici-types is required by debian/nodejs/./extcopies but not available # Typescript definition detected, Fallback to main module ### You SHOULD update your debian/nodejs/./extcopies file! Copy /usr/share/nodejs/yjs -> ./node_modules/ debian/rules override_dh_auto_build make[1]: Entering directory '/<>' tsc --outDir . node_modules/@types/node/ts4.8/globals.d.ts(325,84): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(326,85): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(327,85): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(328,84): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(330,22): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(336,35): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(337,35): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(338,32): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(339,39): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(340,42): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(341,35): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(342,38): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(343,34): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(344,37): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(360,21): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(367,21): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(374,21): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. node_modules/@types/node/ts4.8/globals.d.ts(381,21): error TS2307: Cannot find module 'undici-types' or its corresponding type declarations. make[1]: *** [debian/rules:11: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:8: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 The above is just how the build ends and not necessarily the most relevant part. If required, the full build log is available here: https://people.debian.org/~sanvila/build-logs/202403/ About the archive rebuild: The build was made on virtual machines of type m6a.large from AWS, using sbuild and a reduced chroot with only build-essential packages. If you could not reproduce the bug please contact me privately, as I am willing to provide ssh access to a virtual
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Package: src:mailscripts
Version: 28-1
Severity: serious
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in unstable, your package failed to build:
[...]
debian/rules build
dh build --with elpa --with bash-completion
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
dh_auto_build
make -j2
make[1]: Entering directory '/<>'
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=mdmv \
mdmv.1.pod mdmv.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=mbox2maildir \
mbox2maildir.1.pod mbox2maildir.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=notmuch-slurp-debbug \
notmuch-slurp-debbug.1.pod notmuch-slurp-debbug.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=notmuch-extract-patch \
notmuch-extract-patch.1.pod notmuch-extract-patch.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=maildir-import-patch \
maildir-import-patch.1.pod maildir-import-patch.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=mbox-extract-patch \
mbox-extract-patch.1.pod mbox-extract-patch.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=imap-dl \
imap-dl.1.pod imap-dl.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=email-extract-openpgp-certs \
email-extract-openpgp-certs.1.pod email-extract-openpgp-certs.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=email-print-mime-structure \
email-print-mime-structure.1.pod email-print-mime-structure.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=notmuch-import-patch \
notmuch-import-patch.1.pod notmuch-import-patch.1
pod2man --section=1 --date="Debian Project" --center="User Commands" \
--utf8 \
--name=gmi2email \
gmi2email.1.pod gmi2email.1
mkdir -p completions/bash
register-python-argcomplete email-print-mime-structure
>completions/bash/email-print-mime-structure.tmp
mv completions/bash/email-print-mime-structure.tmp
completions/bash/email-print-mime-structure
mkdir -p completions/bash
register-python-argcomplete imap-dl >completions/bash/imap-dl.tmp
mv completions/bash/imap-dl.tmp completions/bash/imap-dl
make[1]: Leaving directory '/<>'
dh_auto_test
make -j2 check
make[1]: Entering directory '/<>'
./tests/email-print-mime-structure.sh
Testing alternative.eml
Testing attachment.eml
Testing encrypted.eml (PGPy)
/usr/lib/python3/dist-packages/pgpy/constants.py:192:
CryptographyDeprecationWarning: IDEA has been deprecated and will be removed in
a future release
bs = {SymmetricKeyAlgorithm.IDEA: algorithms.IDEA,
/usr/lib/python3/dist-packages/pgpy/constants.py:194:
CryptographyDeprecationWarning: CAST5 has been deprecated and will be removed
in a future release
SymmetricKeyAlgorithm.CAST5: algorithms.CAST5,
/usr/lib/python3/dist-packages/pgpy/constants.py:195:
CryptographyDeprecationWarning: Blowfish has been deprecated and will be
removed in a future release
SymmetricKeyAlgorithm.Blowfish: algorithms.Blowfish,
Testing encrypted.eml (GnuPG PGP/MIME)
Testing simple.eml
Testing smime-encrypted.eml (OpenSSL)
Testing smime-encrypted.eml (GnuPG S/MIME)
gpgsm: issuer certificate (#/CN=Sample LAMPS Certificate Authority) not found
Testing smime-signed.eml
mypy --strict ./email-print-mime-structure
email-print-mime-structure:51: error: Unused "type: ignore" comment
[unused-ignore]
email-print-mime-structure:53: error: Incompatible types in assignment (expression has
type "None", variable has type Module) [assignment]
email-print-mime-structure:77: error: Incompatible types in assignment (expression has type
"Message | str | list[Message | str] | Any", variable has type "list[Message] | str
| bytes | None") [assignment]
email-print-mime-structure:109: error: Incompatible types in assignment (expression has type
"Message | bytes | Any", variable has type "list[Message] | str | bytes |
None") [assignment]
email-print-mime-structure:121: error: Incompatible types in assignment (expression has type
"Message | bytes | Any", variable has type "list[Message] | str | bytes |
None") [assignment]
email-print-mime-structure:181: error: Incompatible types in assignment (expression has type
"Message | str | list[Message | str] | Any", variable has type "list[Message] | str
| bytes | None") [assignment]
Found 6 errors in 1 file (checked 1 source file)
make[1]: *** [Makefile:15: check] Error 1
make[1]:
Bug#1067714: llvm-toolchain-17: Build should use at least one CPU
Package: src:llvm-toolchain-17
Version: 17.0.6-5
Tags: patch
Dear maintainer:
I tried to build this package on a machine with 2 CPUs, 4GB of RAM,
and some swap, and the build stopped unexpectedly with this strange
error message:
LD_LIBRARY_PATH=/<>/build-llvm/lib:$LD_LIBRARY_PATH \
VERBOSE=1 cmake --build build-llvm -j 0 --target stage2 || cat
build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeOut
put.log
The value requires a positive integer argument.
Usage: cmake --build [options] [-- [native-options]]
cmake --build --preset [options] [-- [native-options]]
Options:
= Project binary directory to be built.
--preset , --preset=
= Specify a build preset.
--list-presets[=]
= List available build presets.
--parallel [], -j []
= Build in parallel using the given number of jobs.
If is omitted the native build tool's
default number is used.
[...]
I would expect a message saying "not enough memory" instead,
not a "rant" about how I should use cmake.
However, I believe we could take for granted that the end user
knows what they are doing and simply ensure that NJOBS is
always >= 1 no matter what.
The attached patch tries to do that.
It changes "n==1 ? 1" to "n==1 || n2<=1 ? 1".
Also, it fixes a bug where in some cases the output is
greater than the number of available CPUs.
So, instead of "n2 n,
I propose "n2<=n ? n2 : n" which IMO is a little bit more readable.
Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -59,7 +59,7 @@ else
endif
NJOBS := $(shell mt=`awk '/^(MemAvail|SwapFree)/ { mt += $$2 } END {print mt}'
/proc/meminfo`; \
awk -vn=$(NCPUS) -vmt=$$mt -vm=$(MEM_PER_CPU) \
- 'END { mt/=1024; n2 = int(mt/m); print n==1 ? 1 : n2
Bug#1057548: closed by Debian FTP Masters (reply to Noah Meyerhans ) (Bug#1057548: fixed in cloud-init 24.1.1-1)
found 1057548 24.1.1-1 retitle 1057548 cloud-init: FTBFS: missing Build-Depends on passwd tags 1057548 + patch thanks Hello. I don't quite understand why this bug was closed with this changelog entry: * New upstream version 24.1 (Closes: #1057548) I did not ask for a new upstream version to be packaged, and the upload did not really fix the bug. I assume you just misdiagnosed it. The build log contains this line: RuntimeError: Unable to lock user account 'foo_user'. No tools available. Tried: ['passwd', 'usermod']. and in fact such line disappears when passwd is present in the chroot. The problem is that passwd is no longer build-essential in trixie/sid, so if it's required for building, it needs to be added to Build-Depends. To reproduce, please try using debootstrap from trixie/sid, which finally stops installing a few of required-but-not-build-essential packages. Trivial patch attached. Thanks.--- a/debian/control +++ b/debian/control @@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13), dh-python, iproute2, + passwd, po-debconf, procps , pylint,
Bug#1067188: gdb-mingw-w64: FTBFS in trixie
Package: src:gdb-mingw-w64 Version: 13.1 Severity: serious Tags: ftbfs Dear maintainer: This package FTBFS in trixie with internal compiler error, and that has been the case for several months now. https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/gdb-mingw-w64.html Naturally, the bug is probably in one of the build-dependencies, maybe gcc-mingw-w64 but I'm not 100% sure. So, this bug needs a reassign, please use "affects src:gdb-mingw-w64" after reassign, as the purpose of this report is to make sure that the bug appears here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gdb-mingw-w64 (That way, anybody doing QA work in trixie will know that the fact that this package ftbfs in trixie is already known) Thanks.
Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)
El 3/3/24 a las 17:38, Jeremy Bícha escribió: Control: severity -1 important Control: affects -1 src:gcr On Fri, Mar 1, 2024 at 6:36 AM Santiago Vila wrote: Ignore build test failures on s390x (Closes: #1057562) This is wrong for several reasons. - The bug report did not say anything about s390x. s390x is the only architecture where the flakiness of the gcr:gck / object build test is severe enough to unreasonably interfere with timely building of gcr & gcr4. You keep misrepresenting the bug I reported. The bug report was not about a flaky test in a generic sense. And it was not about the effect of such flaky test in the official buildds either. What the bug report said is that whenever I try to build the package on several virtual machines from AWS of different types, the build fails. ALWAYS. So, this is not about an occasional failure. This is about a permanent failure. Here is my build history: Status: failed gcr4_4.1.0-2_amd64-20230322T215308.971Z Status: failed gcr4_4.1.0-2_amd64-20230322T215447.211Z Status: failed gcr4_4.1.0-2_amd64-20230922T202053.367Z Status: failed gcr4_4.1.0-2_amd64-20230922T202058.856Z Status: failed gcr4_4.1.0-2_amd64-20230922T202121.876Z Status: failed gcr4_4.1.0-2_amd64-20230922T202342.316Z Status: failed gcr4_4.1.0-2_amd64-20230922T202518.944Z Status: failed gcr4_4.1.0-2_amd64-20230922T202604.013Z Status: failed gcr4_4.1.0-2_amd64-20230922T202834.489Z Status: failed gcr4_4.1.0-2_amd64-20230922T202921.776Z Status: failed gcr4_4.1.0-2_amd64-20230930T214526.762Z Status: failed gcr4_4.1.0-2_amd64-20230930T215238.884Z Status: failed gcr4_4.1.0-2_amd64-20230930T215413.813Z Status: failed gcr4_4.1.0-2_amd64-20230930T215359.115Z Status: failed gcr4_4.1.0-2_amd64-20230930T215627.137Z Status: failed gcr4_4.1.0-2_amd64-20230930T215937.574Z Status: failed gcr4_4.1.0-2_amd64-20230930T221515.395Z Status: failed gcr4_4.1.0-2_amd64-20230930T221739.810Z Status: failed gcr4_4.1.0-2_amd64-20231130T041100.202Z Status: failed gcr4_4.1.0-2_amd64-20231205T160411.736Z Status: failed gcr4_4.1.0-2_amd64-20231213T155044.129Z Status: failed gcr4_4.1.0-2_amd64-20231213T160911.601Z Status: failed gcr4_4.1.0-2_amd64-20240129T170626.580Z Status: failed gcr4_4.1.0-2_amd64-20240129T170930.627Z Status: failed gcr4_4.1.0-2_amd64-20240129T171059.244Z Status: failed gcr4_4.1.0-2_amd64-20240129T171811.347Z Status: failed gcr4_4.2.0-3_amd64-20240301T110606.957Z Status: failed gcr4_4.2.0-3_amd64-20240301T110607.721Z Status: failed gcr4_4.2.0-3_amd64-20240301T110608.780Z Status: failed gcr4_4.2.0-3_amd64-20240301T110608.127Z Status: failed gcr4_4.2.0-3_amd64-20240301T110609.765Z Status: failed gcr4_4.2.0-3_amd64-20240301T110718.547Z Status: failed gcr4_4.2.0-3_amd64-20240301T110719.934Z Status: failed gcr4_4.2.0-3_amd64-20240301T110721.878Z This is a violation of a *must* directive in Policy, because Debian policy says this: If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). Debian is full of packages where the build tests and autopkgtests are flaky enough to be disruptive to someone expecting 100% pass rates. This is a strawman. I'm *not* expecting a 100% pass rate. A pass rate of 100% would correspond to a failure rate of 0%. I do not expect a failure rate of 0%. I just expect a failure rate which is *not* 100%. There is currently no one on the Debian GNOME team with the time to investigate and properly fix these issues. In such case the failing test is completely useless and even harmful. When we have unit tests, they are enabled with the aim of "doing something" when they fail. If we do nothing when they fail, we are wasting the time of everybody involved. The occasional failure is enough to remind us of this issue. If this is really about "reminding", I can put a cron job to email you a reminder weekly or monthly. Even a postit note in your monitor would be better than this. But not this. I don't think it's helpful to just disable the test since it may disguise a real problem that someone can work on once they get sufficiently annoyed by the issue. Well, but this is *already* a real problem: The package does not build in some systems. Not an occasional failure, but not at all. Also, it may be important to recognize if the failure rate for this test on official buildds increases significantly. The failure rate did increase on s390x but we don't really treat s390x as a supported Desktop architecture and don't have capacity to spend much time dealing with s390x. And you keep mentioning s390x when the original bug report did not mentio
Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied
tags 1057549 + patch thanks Hi. I looked at the build log and found the problem: The package has a missing build-depends on passwd, which is no longer build-essential in trixie/sid. I am a member of Debian Go (joined to do QA stuff). Would it help if I fix this myself by doing a "Team Upload"? Thanks.--- a/debian/control +++ b/debian/control @@ -68,6 +68,7 @@ Build-Depends: debhelper-compat (= 13), golang-gopkg-natefinch-lumberjack.v2-dev, golang-gopkg-tomb.v2-dev, golang-gopkg-yaml.v2-dev, + passwd, python3, systemd Standards-Version: 4.5.0
Bug#1002789: closed by Debian FTP Masters (reply to Thomas Goirand ) (Bug#1002789: fixed in python-pycdlib 1.12.0+ds1-5)
El 5/3/24 a las 13:51, Lucas Nussbaum escribió: I'm setting the severity to important since we know how to make it build. The bad thing is that this is not a condition which we can express via Build-Depends. Thomas: building a package should never involve adding a "secret sauce" like this. This is what Debian Policy says about package building: "If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships)." Note that it does *not* say "if build-time dependencies are specified and tmp is bind-mounted as tmpfs" or anything like that. Therefore, I still consider this to be a violation of a Policy "must" directive, and I still expect that any and all tests which rely on conditions or properties which may or may not hold in the building machine are buggy and must be disabled. Thanks.
Bug#1057562: closed by Debian FTP Masters (reply to Jeremy Bícha ) (Bug#1057562: fixed in gcr4 4.2.0-2)
reopen 1057562 found 1057562 4.2.0-3 thanks Ignore build test failures on s390x (Closes: #1057562) This is wrong for several reasons. - The bug report did not say anything about s390x. - This is still happening on version 4.2.0-3. I can still reproduce it 100% of the time here, and I'm using amd64. Build log attached. - I included a paragraph saying this which has been completely ignored: If you could not reproduce the bug please contact me privately, as I am willing to provide ssh access to a virtual machine where the bug is fully reproducible. - Even if you don't care about the end user being able to build the package from source and your only concern is flakiness on the official buildds (which is not a good way to "fix" the problem, btw), this is still flaky on the official buildds: https://buildd.debian.org/status/fetch.php?pkg=gcr4=amd64=4.2.0-3=1709067945=0 My offer for a machine where this happens 100% of the time still holds if you need it. Thanks. gcr4_4.2.0-3_amd64-20240301T110721.878Z.gz Description: application/gzip
Bug#1064459: base-files: install aliasing symlinks for merged-/usr DEP17
Hi. Please respect any already existing coding style that you can notice in other parts of base-files. Some examples: Indent in shell script using 2 spaces. Quotes around "triggered" and similar places. (Also, I wonder if it would be possible to create debian/triggers using some sort of dh-exec-like template instead of having extra variables and a for loop in debian/rules). While we are at it: Is there an estimated date when you will want to upload this? Thanks.
Bug#1054386: bookworm-pu: package fssync/1.6-1.1+deb12u1
Hello. I was going to sponsor this upload and we were waiting for approval before upload, but given that 12.5 is approaching and I believe that rejecting an incorrect upload is relatively easy, I've decided to go ahead and make the upload. Please consider for 12.5. Thanks.
Bug#1062435: bookworm-pu: package indent/2.2.12-4+deb12u3
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: ind...@packages.debian.org, sanv...@debian.org Control: affects -1 + src:indent [ Reason ] This upload fixes CVE-2024-0911. [ Impact ] We remain vulnerable if the update is not approved. [ Tests ] I've tested that the bug is fixed. [ Risks ] Low risk. The patch has been already accepted upstream. [ 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 (old)stable [X] the issue is verified as fixed in unstable [ Changes ] See changelog. [ Other info ] I've already uploaded the package.
Bug#1061543: indent: CVE-2024-0911
severity 1061543 important found 1061543 2.2.12-1 found 1061543 2.2.12-4+deb12u2 thanks El 26/1/24 a las 8:52, Moritz Mühlenhoff escribió: Source: indent X-Debbugs-CC: t...@security.debian.org Severity: normal Tags: security Hi, This was assigned CVE-2024-0911: https://lists.gnu.org/archive/html/bug-indent/2024-01/msg1.html If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. [...] Thanks for the report. I've just applied the (code part of the) patch for unstable. Can you confirm that proposed-updates is good enough to fix this in stable? (i.e. no DSA, like other recent previous indent CVEs). Thanks.
Bug#1052902: yosys: FTBFS: make[2]: *** [Makefile:971: docs/gen_images] Error 2
El 3/12/23 a las 19:00, Daniel Gröber escribió: Hi Lucas, On Thu, Oct 26, 2023 at 09:45:53AM +0200, Lucas Nussbaum wrote: As an additional data point, I can still reproduce this. I cannot provide the buildinfo, as sbuild outputs it at the end of successful builds. Doh! Didn't think of that. Something to improve in sbuild I guess :) However, in the build log there's the list of installed packages, which might be sufficient... Since I've sucessfully rebuilt yosys agains unstable and it's still failing for you it's pretty much moot. I just thought you'd have the buildinfos at hand. I'm essentially waiting for make 4.4 to make it into Debian as Santiago pointed out it may help track this down, but if I can't repro this (and I have still never seen this) there's not much I can do without access to a system this repros on. Hi. If you are willing to try the make 4.4 route, you don't really need to wait for the official package to be uploaded for unstanle. You can just download it from ftp.gnu.org, and do the usual "./configure; make". You just have to put the "make" executable as /usr/bin/make inside your chroot (and set some environment variable). Alternatively, I can also create a machine in AWS similar to the ones used by Lucas for the mass rebuilds, please contact me privately for details. Thanks.
Bug#1059360: sbuild: How to use it in combination with faketime?
Package: sbuild
Version: 0.85.0
Severity: wishlist
Hello.
I'm trying to use faketime with sbuild. Currently, I managed to
make it work by replacing dpkg-buildpackage inside the chroot
with a wrapper script:
#!/bin/sh
faketime -f "@2028-12-31 12:00:00" real-dpkg-buildpackage
But I would prefer not to fiddle with the contents of the chroot.
Is there a less intrusive way?
Somewhere in the source I see this hardcoded:
system('/usr/bin/dpkg-buildpackage',
so maybe we would just need some new environment variable
string to be used as a prefix for that.
Thanks.
Bug#1042299: libfirefox-marionette-perl: FTBFS: tests fail
tags 1042299 - trixie sid tags 1042299 + bookworm thanks Hi. I found this bug while rebuilding all packages in bookworm: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/libfirefox-marionette-perl.html I'm fixing the metadata since it's a FTBFS bug. Would be possible to fix it in bookworm, please? Thanks.
Bug#1053334: galera-4: FTBFS because of expired certificates
retitle 1053334 galera-4: FTBFS in bookworm because of expired SSL certificates found 1053334 26.4.13-1 severity 1053334 serious tags 1053334 bookworm thanks Hello. I found about this bug during a rebuild of all packages in bookworm. Could you please fix this in bookworm as well? Packages in stable must build in stable. (I would be willing to help if required). Thanks.
Bug#1057591: octave-vibes: FTBFS: fatal: caught signal Segmentation fault -- stopping myself...
El 20/12/23 a las 21:08, Rafael Laboissière escribió: HOME := $(shell mktemp -d) so that the same directory is never used twice between consecutive builds. Yes, this is a much better solution. Thanks for the suggestion. I am just wondering: is there a simple way to delete the temporary directory after he build is finished ? I don't know, but most people build packages in temporary/disposable chroots, so if the package just writes a few files which are also small, it's not something for which I would worry too much. Personal note: I also used to worry about that in my archive rebuilds. In fact, I collected the information about how much junk each package created at /tmp, with the idea of reporting the extreme cases some day. This was a problem because I was using the "default" profile for schroot (i.e. /etc/schroot/default), which bind-mounts the /tmp in the chroot to the /tmp in the host machine. But now I've recently switched to the "sbuild" profile, which I use with either overlayfs or with file-based chroots, so the chroot used for each package build, including /tmp, is completely new each time. This is really the "normal thing". If you look at any build log at buildd.debian.org, you will see something like this: Purging /<> Not cleaning session: cloned chroot in use Thanks.
