Processed: retitle 1052232 to FTBFS with recent context
Processing commands for cont...@bugs.debian.org: > retitle 1052232 FTBFS with recent context Bug #1052232 [src:mlpost] FTBFS with OCaml 4.14.1 Changed Bug title to 'FTBFS with recent context' from 'FTBFS with OCaml 4.14.1'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1052232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: metafun.mp refers to inexistent metafun.mpii
Processing control commands: > block 1052232 by -1 Bug #1052232 [src:mlpost] FTBFS with OCaml 4.14.1 1052232 was not blocked by any bugs. 1052232 was not blocking any bugs. Added blocking bug(s) of 1052232: 1052298 -- 1052232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052232 1052298: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052298 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1052232: FTBFS with OCaml 4.14.1
Processing control commands: > severity -1 serious Bug #1052232 [src:mlpost] FTBFS with OCaml 4.14.1 Severity set to 'serious' from 'important' -- 1052232: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052232 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: affects 1051933, found 1051933 in 1.0.4-2
Processing commands for cont...@bugs.debian.org: > affects 1051933 + src:pysmi Bug #1051933 [python3-pysnmp-pysmi] python3-pysnmp-pysmi has an undeclared file conflict Added indication that 1051933 affects src:pysmi > found 1051933 1.0.4-2 Bug #1051933 [python3-pysnmp-pysmi] python3-pysnmp-pysmi has an undeclared file conflict Marked as found in versions python-pysmi-lextudio/1.0.4-2. > thanks Stopping processing here. Please contact me if you need assistance. -- 1051933: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051933 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Setting severity to serious after RM bugs have been filed
Processing commands for cont...@bugs.debian.org: > severity 1052231 serious Bug #1052231 [src:gmetadom] FTBFS with OCaml 4.14.1 Severity set to 'serious' from 'important' > severity 1052236 serious Bug #1052236 [src:otags] FTBFS with OCaml 4.14.1 Severity set to 'serious' from 'important' > severity 1052237 serious Bug #1052237 [src:xmlrpc-light] FTBFS with OCaml 4.14.1 Severity set to 'serious' from 'important' > thanks Stopping processing here. Please contact me if you need assistance. -- 1052231: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052231 1052236: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052236 1052237: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052237 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052292: inkscape: missing Breaks+Replaces: inkscape-open-symbols (<< 1.3)
Package: inkscape Version: 1.3+ds-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. This error may also be triggered by having a predecessor package from 'sid' installed while installing the package from 'experimental'. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../8-inkscape_1.3+ds-1_amd64.deb ... Unpacking inkscape (1.3+ds-1) over (1.2.2-2+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-Hgag5N/8-inkscape_1.3+ds-1_amd64.deb (--unpack): trying to overwrite '/usr/share/inkscape/symbols/sjjb-amenity.svg', which is also in package inkscape-open-symbols 1.2.1-1 Errors were encountered while processing: /tmp/apt-dpkg-install-Hgag5N/8-inkscape_1.3+ds-1_amd64.deb cheers, Andreas inkscape-open-symbols=1.2.1-1_inkscape=1.3+ds-1.log.gz Description: application/gzip
Processed: Re: RM: gliv -- RoQA; unmaintained; depends on gtk2
Processing control commands: > severity -1 normal Bug #1049380 [src:gliv] RM: gliv -- RoQA; unmaintained; depends on gtk2 Severity set to 'normal' from 'serious' > reassign -1 ftp.debian.org Bug #1049380 [src:gliv] RM: gliv -- RoQA; unmaintained; depends on gtk2 Bug reassigned from package 'src:gliv' to 'ftp.debian.org'. No longer marked as found in versions gliv/1.9.7-2. Ignoring request to alter fixed versions of bug #1049380 to the same values previously set -- 1049380: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049380 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: RM: pcmanx-gtk2 -- RoQA; dead upstream; depends on gtk2
Processing control commands: > severity -1 normal Bug #1044138 [src:pcmanx-gtk2] RM: pcmanx-gtk2 -- RoQA; dead upstream; depends on gtk2 Severity set to 'normal' from 'serious' > reassign -1 ftp.debian.org Bug #1044138 [src:pcmanx-gtk2] RM: pcmanx-gtk2 -- RoQA; dead upstream; depends on gtk2 Bug reassigned from package 'src:pcmanx-gtk2' to 'ftp.debian.org'. No longer marked as found in versions pcmanx-gtk2/1.3-2. Ignoring request to alter fixed versions of bug #1044138 to the same values previously set -- 1044138: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1044138 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1049380: RM: gliv -- RoQA; unmaintained; depends on gtk2
Control: severity -1 normal Control: reassign -1 ftp.debian.org Please remove gliv. It is unmaintained both upstream and in Debian. Also, it depends on the deprecated gtk2.
Bug#1044138: RM: pcmanx-gtk2 -- RoQA; dead upstream; depends on gtk2
Control: severity -1 normal Control: reassign -1 ftp.debian.org Please remove pcmanx-gtk2. It is dead upstream, unmaintained in Debian, and depends on the deprectated gtk2.
Bug#1042034: nwchem: FTBFS: ld: cannot find -ldangchang: No such file or directory
Package: nwchem Version: 7.0.2-4 Followup-For: Bug #1042034 The problem seems to be specific to mpich, which is a bit peculiar. The openmpi build remains successful.
Bug#1052058: apt: refuses to downgrade itself to a version that works on the system
Apologies. It seems that usrmerge had not successfully performed the merge (another issue). It was installed, as can be seen in my first message, but running /usr/lib/usrmerge/convert-usrmerge manually did the trick. It also merges /lib*. Thank you and with my best regards, On Tue, Sep 19, 2023, at 17:18, David Kalnischkies wrote: > On Mon, Sep 18, 2023 at 07:56:09PM -0400, Philippe Grégoire wrote: >> As such, I can no longer install or remove packages since my system is >> partitioned. I'd like to point out that the above link does not specifically >> mention disk partitioning, but only how files are placed on disk. >> >> Obviously, re-partitioning the system is something I'd like to avoid at the >> moment. >> >> Thinking about it, in the long term, due to the merge and how packagers are >> expected to be able to address files (e.g. /bin/sh vs /usr/bin/sh), I don't >> see any other way than re-partitioning. Re-partitioning will be done by a >> future me. > > It is sort-of the point of /usr-merge that /usr can be another partition > instead of having packaged content split over multiple subdirectories > of / which could all be individual partitions, but only really work if > you mount them all anyhow… (yes, /etc, /var and all that jazz. People > have opinions on that, too. Lets focus on the problem we already have > now instead of pilling additional ones on top). > > > What should be the case is that /usr is a directory and e.g. /bin is > a symlink to /usr/bin. That is what the apt code is trying to check in > a somewhat roundabout way with inode as both /usr and /usr/bin should > point to the same real directory occupying the same inode. > > > That should be the case even if you have /usr on a different partition. > Are you sure your system is properly merged – as in you haven't unmerged > it with e.g. dpkg-fsys-usrunmess or prevent the merge to be executed > automatically by the installation of usrmerge? > > In either case, it is probably better to contact a user support list > to resolve your issue. > > >> P.S. I'm uncertain why /lib isn't also merged with /usr/lib > > It is? The code even checks for /sbin, /bin und /lib – but that isn't > all that /usr-merge entails and APT doesn't really want to be checking > for everything. Just for some easy to verify truths to ensure nothing > went south… like it seems to have happened on your system. > > > Best regards > > David Kalnischkies > > Attachments: > * signature.asc
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Quoting Alexandru Mihail (2023-09-19 23:41:05) > > do you have an estimate when you think you can upload this? This bug has > > now blocked part of my work in Debian for two weeks and I'm unable to do > > another release for my package until this bug gets fixed. > I'm planning to release no later than Friday. okay, I'll wait. Thank you for your quick reply! signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hello, > do you have an estimate when you think you can upload this? > > This bug has now blocked part of my work in Debian for two weeks and > I'm unable > to do another release for my package until this bug gets fixed. > I'm planning to release no later than Friday. I'm also tackling #491078 now, and would prefer to bundle both fixes into 1.30-5 for efficiency reasons and a cleaner update path. > If you are short on time I can also NMU mini-httpd with the changes > to the > service file I proposed in my last mail. > Is that all right with you ? > Thanks! > > cheers, josch Cheers, Alexandru signature.asc Description: This is a digitally signed message part
Bug#1052058: apt: refuses to downgrade itself to a version that works on the system
On Mon, Sep 18, 2023 at 07:56:09PM -0400, Philippe Grégoire wrote: > As such, I can no longer install or remove packages since my system is > partitioned. I'd like to point out that the above link does not specifically > mention disk partitioning, but only how files are placed on disk. > > Obviously, re-partitioning the system is something I'd like to avoid at the > moment. > > Thinking about it, in the long term, due to the merge and how packagers are > expected to be able to address files (e.g. /bin/sh vs /usr/bin/sh), I don't > see any other way than re-partitioning. Re-partitioning will be done by a > future me. It is sort-of the point of /usr-merge that /usr can be another partition instead of having packaged content split over multiple subdirectories of / which could all be individual partitions, but only really work if you mount them all anyhow… (yes, /etc, /var and all that jazz. People have opinions on that, too. Lets focus on the problem we already have now instead of pilling additional ones on top). What should be the case is that /usr is a directory and e.g. /bin is a symlink to /usr/bin. That is what the apt code is trying to check in a somewhat roundabout way with inode as both /usr and /usr/bin should point to the same real directory occupying the same inode. That should be the case even if you have /usr on a different partition. Are you sure your system is properly merged – as in you haven't unmerged it with e.g. dpkg-fsys-usrunmess or prevent the merge to be executed automatically by the installation of usrmerge? In either case, it is probably better to contact a user support list to resolve your issue. > P.S. I'm uncertain why /lib isn't also merged with /usr/lib It is? The code even checks for /sbin, /bin und /lib – but that isn't all that /usr-merge entails and APT doesn't really want to be checking for everything. Just for some easy to verify truths to ensure nothing went south… like it seems to have happened on your system. Best regards David Kalnischkies signature.asc Description: PGP signature
Processed: re: rust-laurel, upcoming rust-bindgen update.
Processing commands for cont...@bugs.debian.org: > Severity 1051146 serious Bug #1051146 [rust-laurel] rust-laurel, upcoming rust-bindgen update. Severity set to 'serious' from 'normal' > Thanks Stopping processing here. Please contact me if you need assistance. -- 1051146: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051146 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1051967 closed by David Prévot (Re: [pkg-php-pear] Bug#1051967: php-fig-log-test: ships /usr/share/php/Psr/Log/Test/*.php, already in php-psr-log-test)
Processing control commands:
> reopen -1
Bug #1051967 {Done: David Prévot } [php-fig-log-test]
php-fig-log-test: ships /usr/share/php/Psr/Log/Test/*.php, already in
php-psr-log-test
Bug reopened
Ignoring request to alter fixed versions of bug #1051967 to the same values
previously set
--
1051967: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1051967: closed by David Prévot (Re: [pkg-php-pear] Bug#1051967: php-fig-log-test: ships /usr/share/php/Psr/Log/Test/*.php, already in php-psr-log-test)
Control: reopen -1 On 15/09/2023 01.18, Debian Bug Tracking System wrote: dpkg: error processing archive […]/php-psr-log-test_1.1.0-1_all.deb (--unpack): trying to overwrite […] which is also in package php-fig-log-test 1.1.0-1 Seems like a false positive: a package trying to overwrite files from the same package (and same version…). These are two distinct packages: vvv php-fig-log-test | 1.1.0-1 | experimental | source, all php-psr-log-test | 1.1.0-1 | unstable | source, all ^^^ Andreas
Bug#1052287: python-unicodedata2: Fails to build with unicode-data 15.1.0
Source: python-unicodedata2 Version: 14.0.0+ds2-1 Severity: serious Tags: ftbfs sid trixie upstream Forwarded: https://github.com/fonttools/unicodedata2/issues/60 python-unicodedata2 fails to build with unicode-data 15.1.0, now in Unstable. A brief outline of needed changes is provided in the upstream bug report. Thank you, Jeremy Bícha
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
Hello, the new Bullseye version of xrdp is identical to the version in Bookworm. Thus the underlying problem is probably more complex and I don't suspect that something is wrong with xrdp itself but more likely with a configuration option or related software packages which do something different than in Bookworm. I have tried to reproduce the problem on Bullseye with Gnome 3 installed. The problem here is that gnome-remote-desktop appears to interfere with xrdp, so I'm not totally sure what is caused by Gnome and what might be a bug in xrdp. Then I restarted the session with Gnome in Xorg mode and a remote connection to the xrdp server succeeded. However I got a black background instead of the normal wallpaper I have. Applications were shown correctly though. I definitely need more information about your setup or xrdp in general to debug this issue. Possible reasons for the behavior may be: 1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new TLS configuration option in 0.9.21.1? 2. graphic drivers ? I read that hardware accelerated drivers may cause such problems. Maybe try to disable them and use software rendering only? LIBGL_ALWAYS_SOFTWARE = true Please also upload the following log files: /var/log/xrdp-sesman.log /var/log/xrdp.log ~/.xsession-errors and journalctl -S -2m or something similar may provide more information about error messages, etc. ~/.xorgxrdp.10.log seems to belong to xorgxrdp. The package is only recommended but I wonder if the problem is potentially caused by it. xrdp is a build- dependency which suggests it might need a rebuild? But on the other hand then recommending the package would be wrong and it should be added to Depends. Someone else would have stumbled upon this sooner I guess. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1052197: sync with xorgxrdp
Hello, The bug is also reported upstream: https://github.com/neutrinolabs/xrdp/issues/2796 the xorgxrdp package must be updated in sync for the xrdp version Emmanuel Blindauer
Processed: Close unused cloned bug report
Processing commands for cont...@bugs.debian.org: > close 1052284 Bug #1052284 [src:pdm] pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends Marked Bug as done > unblock 1043255 by 1052284 Bug #1043255 [ftp.debian.org] RM: pep517 -- ROM; Obsolete, replaced by python-pyproject-hooks 1043255 was blocked by: 1042869 1043002 1052284 1042965 1052285 1043255 was not blocking any bugs. Removed blocking bug(s) of 1043255: 1052284 > thanks Stopping processing here. Please contact me if you need assistance. -- 1043255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043255 1052284: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052284 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
Processing commands for cont...@bugs.debian.org: > clone 1043002 -1 -2 Bug #1043002 [src:pdm] pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends Bug 1043002 cloned as bugs 1052284-1052285 1043255 was blocked by: 1043002 1042869 1042965 1043255 was not blocking any bugs. Added blocking bug(s) of 1043255: 1052284 1043255 was blocked by: 1042965 1052284 1042869 1043002 1043255 was not blocking any bugs. Added blocking bug(s) of 1043255: 1052285 > retitle -2 pdm: Please consider including test artifacts in source build Bug #1052285 [src:pdm] pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends Changed Bug title to 'pdm: Please consider including test artifacts in source build' from 'pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends'. > severity -2 minor Bug #1052285 [src:pdm] pdm: Please consider including test artifacts in source build Severity set to 'minor' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 1043002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043002 1043255: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043255 1052285: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052285 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052282: mythtv-status FTBFS with nocheck profile
Source: mythtv-status Version: 1.1.0-1 Severity: serious Tags: ftbfs mythtv-status fails to build from source when built with the nocheck build profile and option. Since trixie such a failure is considered release critical, because the autoremover relies on correct nocheck annotations. A build log looks like it actually runs tests despite the nocheck option and fails doing so as relevant test dependencies have been annotated . A very simple workaround for this bug is dropping all annotations from debian/control, but actually skipping tests and thus supporting nocheck would be a better solution. Helmut
Bug#1051560: jpeg-xl: FTBFS: failing test conformance_tooling_test
X-Debbugs-CC: ma...@debian.org
On Sat, 09 Sep 2023 16:04:38 -0400 Boyuan Yang wrote:
> Source: jpeg-xl
> X-Debbugs-Cc: by...@debian.org
> Version: 0.7.0-10
> Severity: serious
> Tags: ftbfs sid trixie
>
> Dear Maintainer,
>
> For jpeg-xl/0.7.0-10, it currently fails to build from source in Debian Sid.
> One of the post-build tests will fail:
>
>
> Start 2874: conformance_tooling_test
> 2874/2874 Test #2874: conformance_tooling_test
> ..***Failed
> 0.15 sec
> + CLEANUP_FILES=()
> + trap 'retcode=$?; { set +x; } 2>/dev/null; cleanup' INT TERM EXIT
> + main /<>/obj-x86_64-linux-gnu /usr/share/libjxl-testdata
> ++ mktemp -d
> + local tmpdir=/tmp/tmp.qnjN0F3yQR
> + CLEANUP_FILES+=("${tmpdir}")
> + python3 -c 'import numpy'
> + local build_dir=/<>/obj-x86_64-linux-gnu
> + [[ -z /<>/obj-x86_64-linux-gnu ]]
> + local decoder=/<>/obj-x86_64-linux-gnu/tools/djxl
> + /<>/tools/conformance/generator.py
> --decoder=/<>/obj-x86_64-linux-gnu/tools/djxl
> --output=/tmp/tmp.qnjN0F3yQR --peak_error=0.001 --rmse=0.001
> /usr/share/libjxl-testdata/jxl/blending/cropped_traffic_light.jxl
> /<>/obj-x86_64-linux-gnu/tools/djxl: error while loading shared
> libraries: libjxl_threads.so.0.7: cannot open shared object file: No such
> file or directory
> Generating cropped_traffic_light
> Traceback (most recent call last):
> File "/<>/tools/conformance/generator.py", line 128, in
>
> main()
> File "/<>/tools/conformance/generator.py", line 124, in main
> GenerateConformanceCorpus(args)
> File "/<>/tools/conformance/generator.py", line 70, in
>GenerateConformanceCorpus
> subprocess.check_call(cmd)
> File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command
> '['/<>/obj-x86_64-linux-gnu/tools/djxl',
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/input.jxl',
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference_image.npy',
> '--metadata_out', '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/test.json',
> '--icc_out',
> '/tmp/tmp.qnjN0F3yQR/cropped_traffic_light/reference.icc']' returned non-zero
> exit status 127.
> + retcode=1
>
>
> 99% tests passed, 1 tests failed out of 2872
>
Just made a little bit investigation.
* Previously the test conformance_tooling_test was skipped since python3-numpy
was not installed
during build.
* With recent builds, python3-numpy was introduced as build-dependency
(implicitly) due to
build toolchain changes, thus unskipping the test.
* It looks like upstream has some special handling around such test; please
check
.github/workflows/conformance.yml .
That being said, I am not sure how should we make a proper fix on this issue. I
wish the issue
is no longer present in v0.8.x series to be packaged. Hope that those findings
are useful
to you.
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Bug#1041451: [Sender Not Verified] Re: Bug#1041451: gmap: FTBFS on all !amd64 archs
Hi Andreas, I have decided to restore the non-SIMD binaries. I have just written code to do that, and will release a new version once some large-scale test runs complete successfully. Thanks, Thomas Wu On Tue, Sep 19, 2023 at 8:48 AM Thomas Wu wrote: > > Hi Andreas, > > The GMAP package should compile on both Intel and Apple architectures. I > think we are now requiring SIMD or its equivalent Neon, though, which is > why we are no longer building the *.nosimd binaries. I don't think that's > a problem since every modern computer supports SIMD or Neon. Does Debian > require a non-SIMD target machine? I will try to look at your bug report > to understand what is going on. > > Thanks, > > Thomas Wu > > > On Tue, Sep 19, 2023 at 7:44 AM Andreas Tille wrote: > >> **Warning** The sender address (Andreas Tille ) can not be verified, >> sender email address could be spoofed. Please take care to proceed. >> Control: tags -1 upstream >> Control: forwarded -1 Thomas Wu , Colin K. Watanabe < >> c...@gene.com> >> >> >> Hi Thomas and Colin, >> >> the Debian packaged gmap fails to build since version 2023-06-01 for all >> release architectures besides amd64. You can read about this bug on our >> bug tracker[1]. I think the analysis from Étienne below is a sensible >> explanation for the issue. >> >> It would be really helpful if you could clarify why you disabled SIMD? >> Does this mean you suggest we should provide gmap for amd64 only? >> >> Kind regards >> Andreas. >> >> >> [1] https://bugs.debian.org/1041451 >> >> Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier: >> > Hi, >> > >> > The relevant part of the error message shows that the generic >> > fully scalar gmap.nosimd executable is never built for any cpu >> > architecture: >> > >> > Note: /<>/build/src/gmap.avx2 does not exist. For >> faster speed, may want to compile package on an AVX2 machine >> > Note: /<>/build/src/gmap.sse42 does not exist. For >> faster speed, may want to compile package on an SSE4.2 machine >> > Note: /<>/build/src/gmap.sse41 does not exist. For >> faster speed, may want to compile package on an SSE4.1 machine >> > Note: /<>/build/src/gmap.ssse3 does not exist. For >> faster speed, may want to compile package on an SSSE3 machine >> > Note: /<>/build/src/gmap.sse2 does not exist. For >> faster speed, may want to compile package on an SSE2 machine >> > Note: /<>/build/src/gmap.nosimd does not exist. For >> faster speed, may want to compile package on an non-SIMD machine >> > Error: appropriate GMAP version not found >> > >> > Looking into src/Makefile.am, indeed they seem disabled upstream >> > for the current gmap versions: >> > >> > # intersect-uint2.c requires SIMD >> > #bin_PROGRAMS += gmap.nosimd >> > #bin_PROGRAMS += gmapl.nosimd >> > #bin_PROGRAMS += gsnap.nosimd >> > #bin_PROGRAMS += gsnapl.nosimd >> > >> > My quick attempts to bring the necessary support in the >> > aforementioned intersect-uint2.c file were not very fruitful so >> > far. Something in there looks to prevent use of simde. >> > >> > Anyways, in hope this helps further investigations, >> > -- >> > .''`. Étienne Mollier >> > : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da >> > `. `' sent from /dev/pts/4, please excuse my verbosity >> >`- >> >> >> >> > ___ >> > Debian-med-packaging mailing list >> > debian-med-packag...@alioth-lists.debian.net >> > >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging >> >> >> -- >> http://fam-tille.de >> >>
Bug#1051880: marked as pending in faust
Control: tag -1 pending Hello, Bug #1051880 in faust reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/faust/-/commit/45cc6b46c11a17b219f6aa3672b43aa4b658181c Prevent linking against libPolly rather than fixing the B-D on the correct libpolly-NN-dev package, we just remove the libPolly libraries from the LIBS (it seems they are not needed) Closes: #1051880 (this message was generated automatically) -- Greetings https://bugs.debian.org/1051880
Processed: Bug#1051880 marked as pending in faust
Processing control commands: > tag -1 pending Bug #1051880 [src:faust] faust: FTBFS with llvm-toolchain-16 as default Added tag(s) pending. -- 1051880: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051880 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1037878: ultracopier: diff for NMU version 2.2.6.0-1.1
Hi, Please update to version 2.2.6.8, have critical bug fix for Unix/Linux system (enable able to manipulate non latin char like japan char) alpha_one_x86/BRULE Herman Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management IT, OS, technologies, research & development, security and business department On 9/10/23 04:47, Thomas Preud'homme wrote: Thanks, much appreciated. Feel free to upload it right away. Best regards, Thomas On 10 September 2023 09:12:35 WEST, Marcos Talau wrote: Control: tags 1037878 + patch Control: tags 1037878 + pending Dear maintainer, I've prepared an NMU for ultracopier (versioned as 2.2.6.0-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards.
Bug#1039723: marked as done (pysolfc does not start any more)
Your message dated Tue, 19 Sep 2023 20:30:43 +0200 with message-id and subject line Re: pysolfc does not start any more has caused the Debian Bug report #1039723, regarding pysolfc does not start any more to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1039723: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039723 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: pysolfc Version: 2.6.4-3 Severity: grave Hello, trying to start the program after the upgrade from Debian 11 to 12 shows on the console this error message: $ pysolfc Traceback (most recent call last): File "/usr/games/pysolfc", line 36, in from pysollib.main import main # noqa: E402,I202 ^^ File "/usr/share/games/pysolfc/pysollib/main.py", line 30, in from pysollib.app import Application File "/usr/share/games/pysolfc/pysollib/app.py", line 32, in from pysollib.images import Images, SubsampledImages File "/usr/share/games/pysolfc/pysollib/images.py", line 28, in from pysollib.pysoltk import copyImage, createBottom, createImage, loadImage File "/usr/share/games/pysolfc/pysollib/pysoltk.py", line 35, in from pysollib.tile.tkhtml import * # noqa: F401,F403 ^^ File "/usr/share/games/pysolfc/pysollib/tile/tkhtml.py", line 29, in from pysollib.ui.tktile.tkhtml import Base_HTMLViewer File "/usr/share/games/pysolfc/pysollib/ui/tktile/tkhtml.py", line 24, in import formatter ModuleNotFoundError: No module named 'formatter' Which package must be installed to get the needed python module into the system? -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pysolfc depends on: ii python3 3.11.2-1+b1 ii python3-configobj 5.0.8-1 ii python3-pygame 2.1.2+dfsg-5+b1 ii python3-random2 1.0.1-2.1 ii python3-six 1.16.0-4 ii python3-tk 3.11.2-3 Versions of packages pysolfc recommends: ii python3-pil.imagetk 9.4.0-1.1+b1 Versions of packages pysolfc suggests: pn freecell-solver-bin pn pysolfc-cardsets -- no debconf information --- End Message --- --- Begin Message --- This was already reported twice. Please check the bug tracker before filing another bug.--- End Message ---
Bug#1008708: Regarding pysolfc embedding a python module
On Tue, 6 Sep 2022 10:10:30 -0300 Athos Ribeiro wrote: As I commented in a similar bug in Ubuntu [1], while the fix for this issue is available upstream and seems technically straightforward, it injects a deprecated python module in its code base and re-licenses it as CC0. Only the changes to the file are licensed under CC0, which is clarified by https://github.com/shlomif/PySolFC/commit/f0fb0500ddc35bd34ec6f0ee136342e32f0a3403
Bug#1052177: marked as done (Provides a PostgreSQL extension without depending on the correct server version)
Your message dated Tue, 19 Sep 2023 18:00:12 + with message-id and subject line Bug#1052177: fixed in pg-gvm 22.6.2-1 has caused the Debian Bug report #1052177, regarding Provides a PostgreSQL extension without depending on the correct server version to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1052177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052177 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: pg-gvm Version: 22.4.0-2 Severity: serious Tags: patch Hi, pg-gvm currently ships a single binary package "pg-gvm" that installs files to /usr/lib/postgresql/15/, but doesn't declare that anywhere; the packaging doesn't conform to the established PostgreSQL extension packaging scheme. PostgreSQL 16 is just entering unstable, the package needs to be updated. A branch to fix that is at https://salsa.debian.org/pkg-security-team/pg-gvm/-/merge_requests/1 I plan to NMU this in 10 days to get the PostgreSQL 16 transition forward if I don't hear back otherwise. Thanks, Christoph --- End Message --- --- Begin Message --- Source: pg-gvm Source-Version: 22.6.2-1 Done: Sophie Brun We believe that the bug you reported is fixed in the latest version of pg-gvm, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1052...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sophie Brun (supplier of updated pg-gvm package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 19 Sep 2023 10:36:16 +0200 Source: pg-gvm Binary: postgresql-16-pg-gvm postgresql-16-pg-gvm-dbgsym Architecture: source amd64 Version: 22.6.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Security Tools Changed-By: Sophie Brun Description: postgresql-16-pg-gvm - PostgreSQL extension for ical object manipulation Closes: 1052177 Changes: pg-gvm (22.6.2-1) unstable; urgency=medium . [ Christoph Berg ] * Convert to PostgreSQL extension packaging standards (Closes: #1052177): + Build for all supported PostgreSQL versions using pg_buildext. + Rename binary package to postgresql-PGVERSION-pg-gvm. + Conflicts/Replaces: pg-gvm. * debian/tests: Run regression tests using pgtap. . [ Sophie Brun ] * New upstream version 22.6.2 * Update minimal required version of libgvm-dev * Update debian/copyright * Update Breaks and Replaces versions for compatibility with Kali packages Checksums-Sha1: d45e0b11de1756b753b11c2953c9eed67ab5c851 2163 pg-gvm_22.6.2-1.dsc 17bdf507853ecaf82345d57ef173db189e9d9bf2 39585 pg-gvm_22.6.2.orig.tar.gz 10557a401b883d461457d7e987da571d5359e750 13460 pg-gvm_22.6.2-1.debian.tar.xz 600152644ba66d1a0d73131fb1e857e6cc530174 12278 pg-gvm_22.6.2-1_amd64.buildinfo b2fcace2ab31f41fff24a1c1b0e02894c33afeae 28324 postgresql-16-pg-gvm-dbgsym_22.6.2-1_amd64.deb b0ed9c867e231657f3d22d77f3b8b3f5dec1c4f9 19864 postgresql-16-pg-gvm_22.6.2-1_amd64.deb Checksums-Sha256: ffe6457bf9c89f238a9159fedcfa61309c10f5e6b05aee38fa3f459c22664251 2163 pg-gvm_22.6.2-1.dsc 348b291e094275f840f6a43e638644bf5992ad4f7e748faa5e9d441b4e8f563e 39585 pg-gvm_22.6.2.orig.tar.gz 9bab6970e98f4b716c4a105ce886a8426153a1235d4afc6e3a6eb11121524c39 13460 pg-gvm_22.6.2-1.debian.tar.xz 907a28c5b544c6e4c86f99f6dcfc3b48bcdf93397436a0612cc26aa4c67f7181 12278 pg-gvm_22.6.2-1_amd64.buildinfo 25c515f48d10b93fd6008204fac9d399f2c4c5056d33a7a1cb352a99ec879eb8 28324 postgresql-16-pg-gvm-dbgsym_22.6.2-1_amd64.deb bcb4a3d5b74c8a3fd044cf771678915114edded726fd5618910520e3fa522a2a 19864 postgresql-16-pg-gvm_22.6.2-1_amd64.deb Files: 3dbb7ddc429fd03395193fd4bb62e938 2163 libs optional pg-gvm_22.6.2-1.dsc 456c1448ec0d5195bdaffc1dd1c7b5d5 39585 libs optional pg-gvm_22.6.2.orig.tar.gz bd7a6d7100135de19e3bfde5d5e4880e 13460 libs optional pg-gvm_22.6.2-1.debian.tar.xz 3c44f61ffb433c372c60f6f5e6319906 12278 libs optional pg-gvm_22.6.2-1_amd64.buildinfo 0639713cb3472bd7a80eeb036876eabc 28324 debug optional postgresql-16-pg-gvm-dbgsym_22.6.2-1_amd64.deb c21953ea92a05e53cc328ca6b249dd0a 19864 libs optional postgresql-16-pg-gvm_22.6.2-1_amd64.deb -BEGIN PGP SIGNATURE- Comment: Signed by Sophie Bru
Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade
On Fri, 15 Sep 2023 14:35:08 +0200 "Farblos" wrote: > Not sure whether this is still relevant or just bad luck or whatever ... my > unattended-upgrade failed today because of this issue. Logs available > on request. Work-around was to remove version 3.20+dfsg-7, retrigger > the unattended upgrade, install version 3.20+dfsg-8. So 3.20+dfsg-7 is broken by emacs29 such that it can only be uninstalled, and not upgraded. I'm confident that your logs will show that the -7 is unpacked but no longer configured. If you're curious about what the generated configuration scripts actually do, then check out this article on how to inspect debs: https://blog.packagecloud.io/inspect-extract-contents-debian-packages/ To be honest I'm not totally sure why this unconfigured (or not totally configured) package can't be upgraded, but it can be argued that an upgrade from an undefined state is an unsafe upgrade. I mean the "why", where your logs will show the "what" and the "how" ;) Also, as maintainers our responsibility is reliable oldstable -> stable upgrades, so this kind of transient breakage will sometimes occur in unstable/sid as well as testing. > Thanks for taking care of this package, BTW! Yes, thank you Manphiz! And Farblos, thank you for reaching out :) While it's unfortunate that it was for a bug, it's always nice to hear from real users of mature software. Kind regards, Nicholas signature.asc Description: PGP signature
Bug#1052261: librust-pkcs5-dev: impossible to install: depends on missing package librust-scrypt-0.11-dev
Package: librust-pkcs5-dev Version: 0.7.1-1+b1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 librust-pkcs5-dev depends on missing package librust-scrypt-0.11-dev -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUJ1HsACgkQLHwxRsGg ASGCyQ/+KIHJJDQnT6vwGP0i13f7Xo/lF/2ZOw0MBASlV+8a5/520+1YN4QqXAll u+BCXHCrRyz6Q4OnMsJdCKOBXWWnGOHHW10En6JENWRFRn2xdsp93Vc+2n4mGMx3 6JhI2kobfH5Vlr0wr1bYI1ydnOefyAA5SaHMiAJLHvznisvpbUJaD9U8yVk30ncG yFBKEBY05u83rzGh27GHDb/+//nBob2i/tOIplWR5ynz8+4T7CKbrGEiV1obVfZu dNUdixJ4pqsKFS3iyBp4NrPzJXSD+Ne5s02mO+Xy3arOUb2jDw/08B1xMA6ZkbLL UALEeauPxdUQuKQiJAKxNFfJk7Z0Bab4cNRtim/Uy8t9jrWSLJ49cKwd+J9jfhPa xMvqyQl68nO1W1P6RXQDOm2WZDNIUOLuMaUULyMjLWXRqOwgwUSs4NLqNpbPh8LI rPYze43mnvKCG3y/yk28H2LOK6n+4FhEXWsykn5Lf0xL5uec4DKtK/FRh84MB9D1 dmWtdYjgacrHaPzBnBesBwsm0oWl+mup7/4vIXrK1aee+zyMb4Pfkm8e1FYpCqKG o1T1CeSOfy1u5a7a5eyMHrPHov1oIeFkoumQtZVXGUp+2fkxeq22mg2lSytFFyBk QbuMKJPc3THsAg4Q6P8AqttFxL5hmxdGc+ZQUnVNvw1nQdMYOe8= =ewt/ -END PGP SIGNATURE-
Processed: Re: libtk-img-doc: dpkg extraction error during upgrading
Processing control commands:
> found -1 1:1.4.15+dfsg-2
Bug #1051797 {Done: Sergei Golovan } [libtk-img-doc]
libtk-img-doc: dpkg extraction error during upgrading
Marked as found in versions libtk-img/1:1.4.15+dfsg-2; no longer marked as
fixed in versions libtk-img/1:1.4.15+dfsg-2 and reopened.
--
1051797: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051797
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1051797: libtk-img-doc: dpkg extraction error during upgrading
Followup-For: Bug #1051797 Control: found -1 1:1.4.15+dfsg-2 Removing the readme from the -doc package is not sufficient, you also need to add Breaks+Replaces: libtk-img-doc (<< 1:1.4.15+dfsg-2) to libtk-img in order to properly take over the file on upgrades from 1:1.4.15+dfsg-1 or before. Andreas
Processed: libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev: all ship /usr/include/clog.h
Processing control commands: > found -1 0.0~git20220819.8ec7bd9-3 Bug #1052260 [libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev] libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev: all ship /usr/include/clog.h There is no source info for the package 'libtorch-cuda-dev' at version '0.0~git20220819.8ec7bd9-3' with architecture '' There is no source info for the package 'libtorch-dev' at version '0.0~git20220819.8ec7bd9-3' with architecture '' Marked as found in versions cpuinfo/0.0~git20220819.8ec7bd9-3. > found -1 2.0.1+dfsg-4 Bug #1052260 [libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev] libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev: all ship /usr/include/clog.h There is no source info for the package 'libcpuinfo-dev' at version '2.0.1+dfsg-4' with architecture '' Marked as found in versions pytorch-cuda/2.0.1+dfsg-4 and pytorch/2.0.1+dfsg-4. -- 1052260: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052260 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052260: libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev: all ship /usr/include/clog.h
Package: libcpuinfo-dev,libtorch-cuda-dev,libtorch-dev Severity: serious User: debian...@lists.debian.org Usertags: piuparts fileconflict Control: found -1 0.0~git20220819.8ec7bd9-3 Control: found -1 2.0.1+dfsg-4 Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. libcpuinfo and libtorch seem to ship different versions of the same clog.h header. If this originates from a different project, perhaps it should be packaged separately. cheers, Andreas
Bug#1041451: [Sender Not Verified] Re: Bug#1041451: gmap: FTBFS on all !amd64 archs
Hi Andreas, The GMAP package should compile on both Intel and Apple architectures. I think we are now requiring SIMD or its equivalent Neon, though, which is why we are no longer building the *.nosimd binaries. I don't think that's a problem since every modern computer supports SIMD or Neon. Does Debian require a non-SIMD target machine? I will try to look at your bug report to understand what is going on. Thanks, Thomas Wu On Tue, Sep 19, 2023 at 7:44 AM Andreas Tille wrote: > **Warning** The sender address (Andreas Tille ) can not be verified, > sender email address could be spoofed. Please take care to proceed. > Control: tags -1 upstream > Control: forwarded -1 Thomas Wu , Colin K. Watanabe < > c...@gene.com> > > > Hi Thomas and Colin, > > the Debian packaged gmap fails to build since version 2023-06-01 for all > release architectures besides amd64. You can read about this bug on our > bug tracker[1]. I think the analysis from Étienne below is a sensible > explanation for the issue. > > It would be really helpful if you could clarify why you disabled SIMD? > Does this mean you suggest we should provide gmap for amd64 only? > > Kind regards > Andreas. > > > [1] https://bugs.debian.org/1041451 > > Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier: > > Hi, > > > > The relevant part of the error message shows that the generic > > fully scalar gmap.nosimd executable is never built for any cpu > > architecture: > > > > Note: /<>/build/src/gmap.avx2 does not exist. For > faster speed, may want to compile package on an AVX2 machine > > Note: /<>/build/src/gmap.sse42 does not exist. For > faster speed, may want to compile package on an SSE4.2 machine > > Note: /<>/build/src/gmap.sse41 does not exist. For > faster speed, may want to compile package on an SSE4.1 machine > > Note: /<>/build/src/gmap.ssse3 does not exist. For > faster speed, may want to compile package on an SSSE3 machine > > Note: /<>/build/src/gmap.sse2 does not exist. For > faster speed, may want to compile package on an SSE2 machine > > Note: /<>/build/src/gmap.nosimd does not exist. For > faster speed, may want to compile package on an non-SIMD machine > > Error: appropriate GMAP version not found > > > > Looking into src/Makefile.am, indeed they seem disabled upstream > > for the current gmap versions: > > > > # intersect-uint2.c requires SIMD > > #bin_PROGRAMS += gmap.nosimd > > #bin_PROGRAMS += gmapl.nosimd > > #bin_PROGRAMS += gsnap.nosimd > > #bin_PROGRAMS += gsnapl.nosimd > > > > My quick attempts to bring the necessary support in the > > aforementioned intersect-uint2.c file were not very fruitful so > > far. Something in there looks to prevent use of simde. > > > > Anyways, in hope this helps further investigations, > > -- > > .''`. Étienne Mollier > > : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > > `. `' sent from /dev/pts/4, please excuse my verbosity > >`- > > > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging > > > -- > http://fam-tille.de > >
Processed: found 1051889 in 3.18.0+ds2-1, found 1051738 in 3.18.0+ds2-1, found 1051737 in 3.18.0+ds2-1
Processing commands for cont...@bugs.debian.org: > found 1051889 3.18.0+ds2-1 Bug #1051889 [src:freeimage] freeimage: CVE-2020-22524 Marked as found in versions freeimage/3.18.0+ds2-1. > found 1051738 3.18.0+ds2-1 Bug #1051738 [src:freeimage] freeimage: CVE-2020-21428 Marked as found in versions freeimage/3.18.0+ds2-1. > found 1051737 3.18.0+ds2-1 Bug #1051737 [src:freeimage] freeimage: CVE-2020-21427 Marked as found in versions freeimage/3.18.0+ds2-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1051737: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051737 1051738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051738 1051889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051889 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1051435: upstream fix committed
Control: tags -1 + patch fixed-upstream Hi again, On Wed, 13 Sep 2023 16:17:59 +0200 Timo Röhling wrote: Unfortunately, this bug is *not* resolved; it looks like this is not a false positive but the subclass case which is explicitly mentioned in the documentation: Upstream has fixed this by removing the offending test, as the tested behavior (inheriting Hypothesis tests) is considered unsupported: https://github.com/pytest-dev/pytest-asyncio/commit/fd57e55db1170c029324a7a9c56f86f14468217e Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Processed: upstream fix committed
Processing control commands: > tags -1 + patch fixed-upstream Bug #1051435 [src:python-pytest-asyncio] python-pytest-asyncio: failing autopkgtest Added tag(s) patch and fixed-upstream. -- 1051435: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1037602: ceph: ftbfs with GCC-13
On 9/19/23 17:02, Bo YU wrote: hmm, I try the patch again, but it seems it works on amd64. `apt source ceph` to get ceph_16.2.11+ds-2 and debdiff-apply the patch. I guess maybe you apply the patch on salsa repo. Yes, I did. Also, you might have missed that I prepared the next version in the debian/experimental branch. The debian/unstable only has the merge of upstream tarball, nothing more, so don't use that one. It builds a lot more stuff, but then it also FTBFS. Note that the upstream package prepared for Ubuntu also FTBFS. yes, I notice it. I am trying to `git clone` the ceph source code from salsa in order to rebase the patch on your commit as you mention. But I am stuck in how to get rid of upstream tarball(18.1.2) on debian/unstable and apply my patch. Or could you tell me what your context hot to apply my patch and I can reproduct the FTBFS on my local machines？ I've "git push origin debian/unstable -f" to get a working branch. Please clone again from scratch (I know, it's a huge repo... :/). I really would love to receive help here, packaging version 18, because even reading the failing cmake logs is hard for me... Thanks for your hard work here. I am not sure I can help here, but i will do my best if possbile. Let's first get 16.2.11 fixed in unstable, then maybe your patch can apply on top of 18.2.x too... Thanks for your help, Cheers, Thomas Goirand (zigo)
Bug#1037602: marked as pending in ceph
Control: tag -1 pending Hello, Bug #1037602 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/-/commit/48dc08622e70877aba2095b497aece099a16cc2f * Fix gcc-13 FTBFS. (Closes: #1037602): - fix-gcc-13-issue.patch (thanks to Bo YU). (this message was generated automatically) -- Greetings https://bugs.debian.org/1037602
Processed: Bug#1037602 marked as pending in ceph
Processing control commands: > tag -1 pending Bug #1037602 [src:ceph] ceph: ftbfs with GCC-13 Added tag(s) pending. -- 1037602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037602 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed
Processing commands for cont...@bugs.debian.org: > fixed 1051738 3.18.0+ds2-10 Bug #1051738 [src:freeimage] freeimage: CVE-2020-21428 The source 'freeimage' and version '3.18.0+ds2-10' do not appear to match any binary packages Marked as fixed in versions freeimage/3.18.0+ds2-10. > fixed 1051889 3.18.0+ds2-10 Bug #1051889 [src:freeimage] freeimage: CVE-2020-22524 The source 'freeimage' and version '3.18.0+ds2-10' do not appear to match any binary packages Marked as fixed in versions freeimage/3.18.0+ds2-10. > End of message, stopping processing here. Please contact me if you need assistance. -- 1051738: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051738 1051889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051889 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1037602: ceph: ftbfs with GCC-13
Hi! On Tue, Sep 19, 2023 at 3:45 PM Thomas Goirand wrote: > > On 9/18/23 13:03, Bo YU wrote: > > Source: ceph > > Followup-For: Bug #1037602 > > Tags: patch > > User: debian-ri...@lists.debian.org > > Usertags: riscv64 > > X-Debbugs-Cc: debian-ri...@lists.debian.org > > > > Dear Maintainer, > > > > I found these commits that was trying to fix the issue but it looks like > > they not done yet. I can confrim the attached patch can fix the issue. > > https://salsa.debian.org/ceph-team/ceph/-/commit/9104dcb08ce6e86f4b2f33286938c6a90f659471 > > https://salsa.debian.org/ceph-team/ceph/-/commit/9cc4c414c1729b6a5b101c46cdfea4ab32f179f3 > > > > Or upgrade to 18.1.2 as you have done on salsa, but this maybe cost more > > time to finish. > > > > The reason I am ccing riscv mail list is that the ceph package is a very > > key package and now it was a blocker for riscv64 official rebootstrap > > from my view. > > https://buildd.debian.org/status/package.php?p=ceph > > > > So could you apply it or upgrade to new version at your next upload? > > Hi, > > I tried your patch, and it's not enough, the package continues to FTBFS. > Should it be applied on top of my commits that you linked above? hmm, I try the patch again, but it seems it works on amd64. `apt source ceph` to get ceph_16.2.11+ds-2 and debdiff-apply the patch. I guess maybe you apply the patch on salsa repo. > > Also, you might have missed that I prepared the next version in the > debian/experimental branch. The debian/unstable only has the merge of > upstream tarball, nothing more, so don't use that one. It builds a lot > more stuff, but then it also FTBFS. Note that the upstream package > prepared for Ubuntu also FTBFS. yes, I notice it. I am trying to `git clone` the ceph source code from salsa in order to rebase the patch on your commit as you mention. But I am stuck in how to get rid of upstream tarball(18.1.2) on debian/unstable and apply my patch. Or could you tell me what your context hot to apply my patch and I can reproduct the FTBFS on my local machines？ > > I really would love to receive help here, packaging version 18, because > even reading the failing cmake logs is hard for me... Thanks for your hard work here. I am not sure I can help here, but i will do my best if possbile. BR, Bo > > Cheers, > > Thomas Goirand (zigo) >
Processed: Re: Bug#1041451: gmap: FTBFS on all !amd64 archs
Processing control commands: > tags -1 upstream Bug #1041451 [src:gmap] gmap: FTBFS on all !amd64 archs Added tag(s) upstream. > forwarded -1 Thomas Wu , Colin K. Watanabe Bug #1041451 [src:gmap] gmap: FTBFS on all !amd64 archs Set Bug forwarded-to-address to 'Thomas Wu , Colin K. Watanabe '. -- 1041451: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041451 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1041451: gmap: FTBFS on all !amd64 archs
Control: tags -1 upstream Control: forwarded -1 Thomas Wu , Colin K. Watanabe Hi Thomas and Colin, the Debian packaged gmap fails to build since version 2023-06-01 for all release architectures besides amd64. You can read about this bug on our bug tracker[1]. I think the analysis from Étienne below is a sensible explanation for the issue. It would be really helpful if you could clarify why you disabled SIMD? Does this mean you suggest we should provide gmap for amd64 only? Kind regards Andreas. [1] https://bugs.debian.org/1041451 Am Tue, Aug 15, 2023 at 12:42:09PM +0200 schrieb Étienne Mollier: > Hi, > > The relevant part of the error message shows that the generic > fully scalar gmap.nosimd executable is never built for any cpu > architecture: > > Note: /<>/build/src/gmap.avx2 does not exist. For faster > speed, may want to compile package on an AVX2 machine > Note: /<>/build/src/gmap.sse42 does not exist. For faster > speed, may want to compile package on an SSE4.2 machine > Note: /<>/build/src/gmap.sse41 does not exist. For faster > speed, may want to compile package on an SSE4.1 machine > Note: /<>/build/src/gmap.ssse3 does not exist. For faster > speed, may want to compile package on an SSSE3 machine > Note: /<>/build/src/gmap.sse2 does not exist. For faster > speed, may want to compile package on an SSE2 machine > Note: /<>/build/src/gmap.nosimd does not exist. For > faster speed, may want to compile package on an non-SIMD machine > Error: appropriate GMAP version not found > > Looking into src/Makefile.am, indeed they seem disabled upstream > for the current gmap versions: > > # intersect-uint2.c requires SIMD > #bin_PROGRAMS += gmap.nosimd > #bin_PROGRAMS += gmapl.nosimd > #bin_PROGRAMS += gsnap.nosimd > #bin_PROGRAMS += gsnapl.nosimd > > My quick attempts to bring the necessary support in the > aforementioned intersect-uint2.c file were not very fruitful so > far. Something in there looks to prevent use of simde. > > Anyways, in hope this helps further investigations, > -- > .''`. Étienne Mollier > : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > `. `' sent from /dev/pts/4, please excuse my verbosity >`- > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Processed: Re: RM: rox -- RoQA; dead upstream; depends on gtk2
Processing control commands: > severity -1 normal Bug #1043510 [src:rox] RM: rox -- RoQA; dead upstream; depends on gtk2 Severity set to 'normal' from 'serious' > reassign -1 ftp.debian.org Bug #1043510 [src:rox] RM: rox -- RoQA; dead upstream; depends on gtk2 Bug reassigned from package 'src:rox' to 'ftp.debian.org'. No longer marked as found in versions rox/1:2.11-7. Ignoring request to alter fixed versions of bug #1043510 to the same values previously set -- 1043510: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043510 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1043510: RM: rox -- RoQA; dead upstream; depends on gtk2
Control: severity -1 normal Control: reassign -1 ftp.debian.org Please remove rox. It is orphaned and dead upstream. It also depends on the deprecated gtk2, which will obviously not be fixed. Nobody chimed in on the RM announcement to keep it in Debian.
Bug#1052219: marked as done (unrecognized option '--insert-timestamp=1686475264')
Your message dated Tue, 19 Sep 2023 13:06:03 + with message-id and subject line Bug#1052219: fixed in libgcrypt20 1.10.2-3 has caused the Debian Bug report #1052219, regarding unrecognized option '--insert-timestamp=1686475264' to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1052219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052219 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: binutils-mingw-w64-i686 Version: 2.41-4+11+nmu1 Severity: serious Tags: ftbfs X-Debbugs-Cc: ol...@debian.org, z...@debian.org The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. It causes libgcrypt20, gcc-mingw-w64 FTBFS. These packages use options like --insert-timestamp=1686475264, which is not supported in upstream implementation. I find such option is mentioned on https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries It looks like Debian specific behaviour. --- End Message --- --- Begin Message --- Source: libgcrypt20 Source-Version: 1.10.2-3 Done: Andreas Metzler We believe that the bug you reported is fixed in the latest version of libgcrypt20, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1052...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Metzler (supplier of updated libgcrypt20 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 19 Sep 2023 13:48:32 +0200 Source: libgcrypt20 Architecture: source Version: 1.10.2-3 Distribution: unstable Urgency: medium Maintainer: Debian GnuTLS Maintainers Changed-By: Andreas Metzler Closes: 1052219 Changes: libgcrypt20 (1.10.2-3) unstable; urgency=medium . [ Simon Josefsson ] * Update Homepage: URL. . [ Andreas Metzler ] * Drop --insert-timestamp linker option on mingw*, binutils 2.41 should use SOURCE_DATE_EPOCH automatically and the Debian package has dropped the patch to add the --insert-timestamp option. Closes: #1052219 Checksums-Sha1: da746e22fe9bbb0900a80f9a1411b2896114c4b6 2799 libgcrypt20_1.10.2-3.dsc 5f9b464978f2c375bec99beaa0634695050cd15c 36016 libgcrypt20_1.10.2-3.debian.tar.xz Checksums-Sha256: fb0d993a060bd43f39fd978522bb6506731c0fe633179206aa21411f56575c32 2799 libgcrypt20_1.10.2-3.dsc 126314acd71a9d856c998bf01898059e4ab1860ce8359d1dc7ed50540776b414 36016 libgcrypt20_1.10.2-3.debian.tar.xz Files: 64690907e26e694bc3960048d1a7e35e 2799 libs optional libgcrypt20_1.10.2-3.dsc f6d47767de005d8c9f94d8a1f0906687 36016 libs optional libgcrypt20_1.10.2-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE0uCSA5741Jbt9PpepU8BhUOCFIQFAmUJjpoACgkQpU8BhUOC FISbhA/+PIfU0qrLidhSRFeDcp7mo1DrBhRIcKbUA2BOOQ1XVgekubHORyC4TRVQ hzp6/nxpMVuk5yTUNRgh39zN2NGOKihlmNccqI7MP6QFy+/a1zpmSVYhqEqpxl6C q+LAl1fAApqV5mJ8MQ5mCsSe9Sc6nWBMpmuHf5PYcB2/RRWS506RSc8NKU/LPB6R txUNtXUI5xqu/x1C4lB0rlLkRu2TuJdSb09Zzs0q8WhaClzHgB1A7bY8jN5YuFtR rxdJutCO5gTxAjiSqQYzZ9tqsaQIen7UYDbnGJeB7cotRp8Kl0LN2Zn6c8wzfM+X CKarcuos92GWO86kIlRUnO3KGxsa+27O2PKU9Cy638ckzalJrv/bOb6hvAtC3eIy 1B53gIYDVQiZMKC/xy7P7T3tE3WpUZKxNO/VkKdPPe41Ez5sDj0u2m5G9GRkGmen /eWmcc+H3z/CKh+mkLddOsROL2Heg6X2DgbgF9huSV3P/J4eSPPplIMun+/Whkq3 /Hq9jrXz9NmNboG/H4V5f7MAPaThKJU6T6wsFV3mM7TLkQiJDPSHahzTvH80tG/l ltgz0Tg4fVsGy6FHhr5FUqPm0rliK42nhvJ0RLBCTcWb2UAFXjFbSG1ibvpSF9sb idHkRqZ+4U+Ynzl2jGNB1fzH1OJIjKPtsuU+laV1WfFU880Z5Rw= =TjZW -END PGP SIGNATURE End Message ---
Processed: tagging 1052219
Processing commands for cont...@bugs.debian.org: > tags 1052219 - moreinfo Bug #1052219 [src:libgcrypt20] unrecognized option '--insert-timestamp=1686475264' Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1052219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052219 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
On 2023-09-19 Shengjing Zhu wrote: > On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler wrote: [...] > > Looking at the changelog entry > > * Drop specify-timestamp.patch, applied upstream in binutils 2.41 > > (Closes: #1042734) > > changing the rdeps does not make any sense at all, since the > > --insert-timestamp support is now supposed to be available upstream? > > Since binutils-mingw-w64-i686 is reported to be 2.41 the support should > > be available. So is binutils-mingw-w64-i686 actually 2.41 and if yes, > > why does "applied upstream" not hold? > Upstream implements it in a different way, it doesn't take argument in > --insert-timestamp option, it just looks SOURCE_DATE_EPOCH implicitly. > Ref > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087 Thanks for the explanation. cu Andreas
Bug#1052243: dkms: Signature keys unexpectedly overridden
Package: dkms Version: 3.0.11-3 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? Enrolled my own secureboot key chain (PK, KEK, db) and wanted dkms to sign kernel modules automatically. * What exactly did you do (or not do) that was effective (or ineffective)? Set `mok_signing_key=` and `mok_certificate` in `/etc/dkms/framework.conf` to my DB.key/DB.crt and then installed the `nvidia-driver` using apt. * What was the outcome of this action? My DB.key and DB.crt were overridden by some new keys. * What outcome did you expect instead? Even if my configuration is wrong, I would never expect that setting `mok_signing_key=` overriddes anything. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dkms depends on: ii build-essential 12.10 ii dpkg-dev 1.22.0 ii gcc [c-compiler] 4:13.2.0-1 ii gcc-13 [c-compiler] 13.2.0-3 ii kmod 30+20230601-1 ii lsb-release 12.0-2 ii make 4.3-4.1 ii patch2.7.6-7 Versions of packages dkms recommends: ii fakeroot 1.32.1-1 ii linux-headers-amd64 [linux-headers-generic] 6.4.13-1 ii sudo 1.9.14p2-1 Versions of packages dkms suggests: ii e2fsprogs 1.47.0-2+b1 pn menu -- Configuration Files: /etc/dkms/framework.conf changed: -- no debconf information
Bug#1042338: dnf: FTBFS: dh_auto_test: error: cd build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 ARGS=-VV returned exit code 2
Control: tags -1 pending On Wed, 26 Jul 2023 22:20:02 +0200 Lucas Nussbaum wrote: > Source: dnf > Version: 4.14.0-4 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20230726 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This looks like a crash when logging, probably due to a new version of python3 or sqlite. I've pushed an NMU disabling build-time tests to DELAYED/3 so that we can get dnf back in testing, as it works fine. Debdiff: diff -Nru dnf-4.14.0/debian/changelog dnf-4.14.0/debian/changelog --- dnf-4.14.0/debian/changelog 2023-05-23 08:08:24.0 +0100 +++ dnf-4.14.0/debian/changelog 2023-09-19 10:30:15.0 +0100 @@ -1,3 +1,11 @@ +dnf (4.14.0-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Disable build tests, python3/sqlite3 are crashing while logging. +(Closes: #1042338) + + -- Luca Boccassi Tue, 19 Sep 2023 10:30:15 +0100 + dnf (4.14.0-4) unstable; urgency=medium * Fix default DNF const PYTNON_INSTALL_DIR. Closes: #1034828. diff -Nru dnf-4.14.0/debian/rules dnf-4.14.0/debian/rules --- dnf-4.14.0/debian/rules 2023-05-23 08:08:24.0 +0100 +++ dnf-4.14.0/debian/rules 2023-09-19 10:30:00.0 +0100 @@ -56,9 +56,11 @@ # Maybe rip that out. # When building with sbuild, users do not have a home directory if /home is # shadowed. Replace HOME with a known directory. +# Tests are failing with new python/sqlite3 due to a segfault when logging, +# disable them for now. See: https://bugs.debian.org/1042338 override_dh_auto_test: - mkdir '$(CURDIR)/debian/tests-home' - TERM='xterm' HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-VV' +# mkdir '$(CURDIR)/debian/tests-home' +# TERM='xterm' HOME='$(CURDIR)/debian/tests-home' dh_auto_test --builddirectory=build -- ARGS='-VV' override_dh_missing: dh_missing --fail-missing Full decoded backtrace: #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 0x77d066c9 in __printf_buffer (buf=buf@entry=0x7fffae50, format=0x761a6b0a "%s: %s: %s\n", ap=0x7fffaf40, mode_flags=2) at ./stdio-common/vfprintf-process-arg.c:435 #2 0x77d272d2 in __vsnprintf_internal (string=string@entry=0x0, maxlen=maxlen@entry=0, format=format@entry=0x761a6b0a "%s: %s: %s\n", args=args@entry=0x7fffaf40, mode_flags=mode_flags@entry=2) at ./libio/vsnprintf.c:96 #3 0x77dc08a4 in ___vsnprintf_chk (s=s@entry=0x0, maxlen=maxlen@entry=0, flag=flag@entry=1, slen=slen@entry=18446744073709551615, format=format@entry=0x761a6b0a "%s: %s: %s\n", ap=ap@entry=0x7fffaf40) at ./debug/vsnprintf_chk.c:34 #4 0x76127197 in vsnprintf (__ap=0x7fffaf40, __fmt=0x761a6b0a "%s: %s: %s\n", __n=0, __s=0x0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:68 #5 rpmlog (code=4, fmt=0x761a6b0a "%s: %s: %s\n") at ./rpmio/rpmlog.c:446 #6 0x760692f7 in renderLogMsg (iErrCode=283, zFormat=, ap=ap@entry=0x7fffb180) at ./src/printf.c:1315 #7 0x760693c7 in sqlite3_log (iErrCode=iErrCode@entry=283, zFormat=zFormat@entry=0x760cf268 "recovered %d frames from WAL file %s") at ./src/printf.c:1326 #8 0x760ac56d in walIndexRecover (pWal=0x11ff868) at ./src/wal.c:1589 #9 walIndexReadHdr (pWal=pWal@entry=0x11ff868, pChanged=pChanged@entry=0x7fffb42c) at ./src/wal.c:2694 #10 0x760aceab in walTryBeginRead (pWal=pWal@entry=0x11ff868, pChanged=pChanged@entry=0x7fffb42c, useWal=useWal@entry=0, cnt=cnt@entry=1) at ./src/wal.c:2996 #11 0x760ad362 in walBeginReadTransaction (pChanged=0x7fffb42c, pWal=0x11ff868) at ./src/wal.c:3302 #12 sqlite3WalBeginReadTransaction (pWal=0x11ff868, pChanged=pChanged@entry=0x7fffb42c) at ./src/wal.c:3386 #13 0x7605b61e in pagerBeginReadTransaction (pPager=0x11f3c58) at ./src/pager.c:3209 #14 sqlite3PagerSharedLock (pPager=0x11f3c58) at ./src/pager.c:5373 #15 0x75fd6d38 in lockBtree (pBt=0x121cae8) at ./src/btree.c:3228 #16 btreeBeginTrans (p=0x1193ea8, wrflag=0, pSchemaVersion=0x0) at ./src/btree.c:3625 #17 0x75fddadf in sqlite3BtreeBeginTrans (p=, wrflag=wrflag@entry=0, pSchemaVersion=pSchemaVersion@entry=0x0) at ./src/btree.c:3718 #18 0x760662ad in sqlite3InitOne (db=0x12124a8, iDb=iDb@entry=0, pzErrMsg=pzErrMsg@entry=0x7fffb938, mFlags=mFlags@entry=0) at ./src/prepare.c:261 #19 0x760664d4 in sqlite3Init (db=db@entry=0x12124a8, pzErrMsg=pzErrMsg@entry=0x7fffb938) at ./src/prepare.c:455 #20 0x7606651f in sqlite3ReadSchema (pParse=pParse@entry=0x7fffb930) at ./src/prepare.c:481 #21 0x7606395d in sqlite3Pragma (pParse=pParse@entry=0x7fffb930, pId1=pId1@entry=0x12a8c30, pId2=pId2@entry=0x12a8c48, pValue=pValue@entry=0x12a8c78, minusFlag=minusFlag@entry=0) at
Processed: insighttoolkit5: Use full ::itk namespace in itkMacro.h
Processing commands for cont...@bugs.debian.org: > retitle 1052223 insighttoolkit5: Use full ::itk namespace in itkMacro.h Bug #1052223 [src:insighttoolkit5] sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared Changed Bug title to 'insighttoolkit5: Use full ::itk namespace in itkMacro.h' from 'sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1052223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052223 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: dnf: FTBFS: dh_auto_test: error: cd build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 ARGS=-VV returned exit code 2
Processing control commands: > tags -1 pending Bug #1042338 [src:dnf] dnf: FTBFS: dh_auto_test: error: cd build && make -j8 test ARGS\+=--verbose ARGS\+=-j8 ARGS=-VV returned exit code 2 Added tag(s) pending. -- 1042338: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042338 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: [Debian-med-packaging] Bug#1039529: Bug#1039529: Bug#1039529: sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared
Processing control commands: > clone -1 -2 Bug #1039529 [src:sight] sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared Bug 1039529 cloned as bug 1052223 > reassign -2 src:insighttoolkit5 5.3.0-5 Bug #1052223 [src:sight] sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared Bug reassigned from package 'src:sight' to 'src:insighttoolkit5'. No longer marked as found in versions sight/21.1.1-3. Ignoring request to alter fixed versions of bug #1052223 to the same values previously set Bug #1052223 [src:insighttoolkit5] sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared Marked as found in versions insighttoolkit5/5.3.0-5. -- 1039529: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039529 1052223: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052223 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1039529: [Debian-med-packaging] Bug#1039529: Bug#1039529: Bug#1039529: sight: FTBFS: /<>/libs/io/itk/helper/ProgressItkToFw.hxx:48:5: error: ‘::Create’ has not been declared
Control: clone -1 -2 Control: reassign -2 src:insighttoolkit5 5.3.0-5 Hi Flavien On Mon, 18 Sept 2023 at 14:24, Flavien Bridault wrote: > > My message was maybe missed during the summer, I give a new attempt... I can > offer a hand to provide the ITK patch if that can help... Let me try cloning and reassigning this bug to insighttoolkit5. Regards Graham
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler wrote: > > Control: tags 1052219 moreinfo > > On 2023-09-19 Shengjing Zhu wrote: > > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > > Package: binutils-mingw-w64-i686 > > > Version: 2.41-4+11+nmu1 > [...] > >> The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. > >> It causes libgcrypt20, gcc-mingw-w64 FTBFS. > >> > >> These packages use options like --insert-timestamp=1686475264, > >> which is not supported in upstream implementation. > >> > >> I find such option is mentioned on > >> https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries > >> It looks like Debian specific behaviour. > > > Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more > > sense. > > > Looking at the changelog entry > * Drop specify-timestamp.patch, applied upstream in binutils 2.41 > (Closes: #1042734) > changing the rdeps does not make any sense at all, since the > --insert-timestamp support is now supposed to be available upstream? > Since binutils-mingw-w64-i686 is reported to be 2.41 the support should > be available. So is binutils-mingw-w64-i686 actually 2.41 and if yes, > why does "applied upstream" not hold? Upstream implements it in a different way, it doesn't take argument in --insert-timestamp option, it just looks SOURCE_DATE_EPOCH implicitly. Ref https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087 > > Nicholas (as NMUer) - can you explain? > -- Shengjing Zhu
Processed: Re: Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Processing control commands: > tags 1052219 moreinfo Bug #1052219 [src:libgcrypt20] unrecognized option '--insert-timestamp=1686475264' Added tag(s) moreinfo. -- 1052219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052219 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Control: tags 1052219 moreinfo On 2023-09-19 Shengjing Zhu wrote: > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > Package: binutils-mingw-w64-i686 > > Version: 2.41-4+11+nmu1 [...] >> The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. >> It causes libgcrypt20, gcc-mingw-w64 FTBFS. >> >> These packages use options like --insert-timestamp=1686475264, >> which is not supported in upstream implementation. >> >> I find such option is mentioned on >> https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries >> It looks like Debian specific behaviour. > Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more > sense. Looking at the changelog entry * Drop specify-timestamp.patch, applied upstream in binutils 2.41 (Closes: #1042734) changing the rdeps does not make any sense at all, since the --insert-timestamp support is now supposed to be available upstream? Since binutils-mingw-w64-i686 is reported to be 2.41 the support should be available. So is binutils-mingw-w64-i686 actually 2.41 and if yes, why does "applied upstream" not hold? Nicholas (as NMUer) - can you explain? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Processed: closing 1037604
Processing commands for cont...@bugs.debian.org:
> # built with gcc-13 as default on the buildds
> close 1037604 116.0.5845.140-1
Bug #1037604 {Done: Timothy Pearson }
[src:chromium] chromium: ftbfs with GCC-13
Marked as fixed in versions chromium/116.0.5845.140-1.
Bug #1037604 {Done: Timothy Pearson }
[src:chromium] chromium: ftbfs with GCC-13
Bug 1037604 is already marked as done; not doing anything.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1037604: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037604
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Processing control commands: > reassign -1 src:libgcrypt20 1.10.2-2 Bug #1052219 [binutils-mingw-w64-i686] unrecognized option '--insert-timestamp=1686475264' Bug reassigned from package 'binutils-mingw-w64-i686' to 'src:libgcrypt20'. No longer marked as found in versions binutils-mingw-w64/11+nmu1. Ignoring request to alter fixed versions of bug #1052219 to the same values previously set Bug #1052219 [src:libgcrypt20] unrecognized option '--insert-timestamp=1686475264' Marked as found in versions libgcrypt20/1.10.2-2. > clone -1 -2 Bug #1052219 [src:libgcrypt20] unrecognized option '--insert-timestamp=1686475264' Bug 1052219 cloned as bug 1052220 > reassign -2 src:gcc-mingw-w64 25.2 Bug #1052220 [src:libgcrypt20] unrecognized option '--insert-timestamp=1686475264' Bug reassigned from package 'src:libgcrypt20' to 'src:gcc-mingw-w64'. No longer marked as found in versions libgcrypt20/1.10.2-2. Ignoring request to alter fixed versions of bug #1052220 to the same values previously set Bug #1052220 [src:gcc-mingw-w64] unrecognized option '--insert-timestamp=1686475264' Marked as found in versions gcc-mingw-w64/25.2. -- 1052219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052219 1052220: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052220 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Control: reassign -1 src:libgcrypt20 1.10.2-2 Control: clone -1 -2 Control: reassign -2 src:gcc-mingw-w64 25.2 On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > Package: binutils-mingw-w64-i686 > Version: 2.41-4+11+nmu1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: ol...@debian.org, z...@debian.org > > The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. > It causes libgcrypt20, gcc-mingw-w64 FTBFS. > > These packages use options like --insert-timestamp=1686475264, > which is not supported in upstream implementation. > > I find such option is mentioned on > https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries > It looks like Debian specific behaviour. Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more sense. -- Shengjing Zhu
Bug#1037602: ceph: ftbfs with GCC-13
On 9/18/23 13:03, Bo YU wrote: Source: ceph Followup-For: Bug #1037602 Tags: patch User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear Maintainer, I found these commits that was trying to fix the issue but it looks like they not done yet. I can confrim the attached patch can fix the issue. https://salsa.debian.org/ceph-team/ceph/-/commit/9104dcb08ce6e86f4b2f33286938c6a90f659471 https://salsa.debian.org/ceph-team/ceph/-/commit/9cc4c414c1729b6a5b101c46cdfea4ab32f179f3 Or upgrade to 18.1.2 as you have done on salsa, but this maybe cost more time to finish. The reason I am ccing riscv mail list is that the ceph package is a very key package and now it was a blocker for riscv64 official rebootstrap from my view. https://buildd.debian.org/status/package.php?p=ceph So could you apply it or upgrade to new version at your next upload? Hi, I tried your patch, and it's not enough, the package continues to FTBFS. Should it be applied on top of my commits that you linked above? Also, you might have missed that I prepared the next version in the debian/experimental branch. The debian/unstable only has the merge of upstream tarball, nothing more, so don't use that one. It builds a lot more stuff, but then it also FTBFS. Note that the upstream package prepared for Ubuntu also FTBFS. I really would love to receive help here, packaging version 18, because even reading the failing cmake logs is hard for me... Cheers, Thomas Goirand (zigo)
Processed: affects 1052219
Processing commands for cont...@bugs.debian.org: > affects 1052219 + libgcrypt20 gcc-mingw-w64 Bug #1052219 [binutils-mingw-w64-i686] unrecognized option '--insert-timestamp=1686475264' Added indication that 1052219 affects libgcrypt20 and gcc-mingw-w64 > thanks Stopping processing here. Please contact me if you need assistance. -- 1052219: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052219 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
