Bug#1065721: simage: FTBFS: error: conflicti ng types for ‘GifQuantizeBuffer’; have ‘int(unsigned int, unsigned int, int *, GifBy teType *, GifByteType *, GifByteType *, GifByteType *, GifColo
Control: severity -1 normal thanks On Sat, 9 Mar 2024 13:03:05 +0100 Sebastian Ramacher wrote: > Source: simage > Version: 1.8.3+ds-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) The bug is fixed in unstable. But the promotion to testing is held up by weird dependency issues. I'm downgrading the bug to prevent removal from testing. I see no reason to remove a package that does build properly in unstable. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1062170: glw: NMU diff for 64-bit time_t transition
Hi,
Package glw has a serious bug against it because of an unapplied 64-bit time
patch. I don't know why it is not applied, but Michael Crusoe raised some
relevant questions about it, quoted in full below. Would the patch submitter
be able to review and advise?
On Mon, 11 Mar 2024 13:34:42 +0100 "Michael R. Crusoe"
wrote:
> I don't think this patch was effective. There is no package rename and
> the build log from experimental contains the following warning:
>
> > dpkg-gencontrol: warning: Provides field of package libglw1-mesa:
> substitution variable ${t64:Provides} used, but is not defined
signature.asc
Description: This is a digitally signed message part.
Bug#1066702: libcdk5: FTBFS: configure: error: No curses header-files found
Control: tags 1066702 + pending On Wed, 13 Mar 2024 13:08:23 +0100 Lucas Nussbaum wrote: > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Uploaded new upstream version to experimental, which fixes this bug. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]
Control: tags 1065779 + pending On Wednesday, March 13, 2024 5:53:11 A.M. CDT Thomas Dickey wrote: > upgrading really is the simplest solution - not much depends on this, > and nothing cares about the actual version: I have uploaded the latest upstream to experimental, which should fix this. Unfortunately, the arm builds fail for an unrelated reason -- build-dep installability problems. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1036869: O: ghostscript -- interpreter for the PostScript language and for PDF
retitle 1022718 'ITA: ghostscript -- interpreter for the PostScript language and for PDF' owner 1022718 s...@debian.org done 1036869 signature.asc Description: This is a digitally signed message part.
Bug#1036869: O: ghostscript -- interpreter for the PostScript language and for PDF
On Mon, 24 Oct 2022 15:17:20 +0200 Jonas Smedegaard wrote: > I have orphaned the ghostscript package, due to lack of time. I'm willing to take on -- and hopefully, share -- the ghostscript maintenance. If anyone wants to team up, let me know! -Steve signature.asc Description: This is a digitally signed message part.
Bug#1057344: libgmp10: major formatted output function bug with %c and the value 0
severity 1057344 normal thanks On Sun, 3 Dec 2023 21:10:39 +0100 Vincent Lefevre wrote: > Package: libgmp10 > Version: 2:6.2.1+dfsg1-1.1 > Severity: grave > Tags: security upstream > Justification: user security hole I understand the bug may have severe consequences but it doesn't appear to rise to the level of grave in my opinion. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1039529: applied patch to ITK
Hi, Just FYI: I applied the suggested patch (thanks Flavien!) to ITK. Let me know if "sight" now builds. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1052223: marked as pending in insighttoolkit
Control: tag -1 pending Hello, Bug #1052223 in insighttoolkit 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/med-team/insighttoolkit/-/commit/d47841b9d2d96c47ab7a98a2476974b45329982d Use full ::itk namespace in itkMacro. Applied upstream patch identified by Flavien Bridault. Closes: #1052223. (this message was generated automatically) -- Greetings https://bugs.debian.org/1052223
Bug#1049952: csh: maintained by ubuntu-devel-disc...@lists.ubuntu.com
On Thu, 17 Aug 2023 11:34:56 +0200 Lucas Nussbaum wrote: > Source: csh > Version: 20110502-7 > Severity: serious Is this really a serious enough issue to warrant removal from Debian? > > Hi, > > this package is maintained by ubuntu-devel-disc...@lists.ubuntu.com, > which is not a suitable contact point for Debian packages maintenance > according to https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > This is most likely due to generating the source package on an Ubuntu > machine. I think there's some magic that replaces the Maintainer field > in the Ubuntu tooling. > > signature.asc Description: This is a digitally signed message part.
Bug#1040334: facet-analyser - build-depends on conflicting packages
On Tuesday, July 4, 2023 10:03:27 A.M. CDT Peter Green wrote: > Package: facet-analyser > Version: 0.0~git20221121142040.6be10b8+ds1-3 > Tags: trixie, sid > Severity: serious > Justification: rc policy - "packages must be buildable within the same > release" User: debian...@lists.debian.org > Usertags: edos-uninstallable > x-debbugs-cc: s...@debian.org > > facet-analyser build-depends on both python3-paraview and > libinsighttoolkit5-dev > > unfortunately, libinsighttoolkit5-dev recently added a dependency on > libvtk9-dev which depends on python3-vtk9 which conflicts with > python3-paraview. > > I am not familiar enough with the packages in question to know what the > most appropriate way to untangle this is. That's curious. I don't know either. My questions are: why do python3-vtk9 and python3-paraview conflict, and could the issue be solved another way? -Steve signature.asc Description: This is a digitally signed message part.
Bug#1039903: libinsighttoolkit5-dev: Forcing C++14 makes plastimatch FTBFS
On Thu, 29 Jun 2023 13:40:42 +0300 Adrian Bunk wrote: > 1153 | #error\ > | ^~ > 1154 | DCMTK was configured to use C++17 features, but your compiler does not or was not configured to provide them. > | ~ > ... > > > > This is due to: > /usr/lib/x86_64-linux-gnu/cmake/ITK-5.3/ITKInitializeCXXStandard.cmake: set(CMAKE_CXX_STANDARD 14) # Supported values are 14, 17, 20, and 23. That is just the default. Override it for the plastimatch build by adding set(CMAKE_CXX_STANDARD 17) to the plastimatch CMakeLists.txt file. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1039528: plastimatch: FTBFS: Could not find a package configuration file provided by "VTK"
On Monday, June 26, 2023 6:15:06 P.M. CDT Adrian Bunk wrote: > Control: reassign -1 libinsighttoolkit5-dev 5.3.0-3 > Control: affects -1 src:plastimatch > > There are actually tow separate issues, both in libinsighttoolkit5-dev: Thanks for bringing this to my attention. > 1. The VTK build dependencies for the recent VTK changes also hae to >become dependencies of libinsighttoolkit5-dev. I confirmed this bug, and fixed it in a rev -4 upload of ITK. I confirmed the issue and the fix by building elastix, which depends on ITK in the same manner. > In file included from > /<>/src/plastimatch/base/dcmtk_config.h:16, from > /<>/src/plastimatch/base/metadata.h:12, from > /<>/src/plastimatch/base/astroid_dose.h:8, from > /<>/src/plastimatch/base/astroid_dose.cxx:7: > /usr/include/dcmtk/config/osconfig.h:1153:2: error: invalid preprocessing > directive #errorDCMTK 1153 | #error\ > > | ^~ > > 1154 | DCMTK was configured to use C++17 features, but your compiler does > not or was not configured to provide them. > | ~ > > 2. This is caused by libinsighttoolkit5-dev injecting -std=c++14 into >reverse dependencies, the fix is likely something like This is less clear to me. Elastix also build-depends on dcmtk and doesn't show this issue. I think ITK uses C++14 as a minimum but you ought to be able to build with higher levels. At work, we build with a C++20 compiler. Thus: I am closing this bug with rev -4 fixing the first mentioned issue. If I am wrong about the second, please open a second bug. Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1036603: libinventor1: broken symlinks: /usr/share/inventor/fonts/Century-Schoolbook-* -> /usr/share/fonts/X11/Type1/c0590*l.pfb
On Tue, 23 May 2023 10:21:29 +0200 Andreas Beckmann wrote: > fonts-urw-base35 does not provide the old "numeric" font names > gsfonts-x11 had. Thanks for this. Do you happen to know of a package that does ship those fonts, even if a different name? > (gsfonts-x11 is now an empty transitional package, > so you could drop that alternative dependency.) > > Feel free to downgrade the severity if the missing fonts are harmless. I couldn't say "harmless", but "mostly harmless", I'd think. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup
Severity: normal thanks On Tue, 25 Apr 2023 22:49:03 -0500 Steven Robbins wrote: > Given that no-one else has reported this, > I'm leaning towards downgrading the severity to keep digikam in the upcoming > release. Setting severity to normal. If anyone reading this has encountered this bug, please reply to let us know. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup
On Tuesday, April 25, 2023 12:50:39 P.M. CDT Rainer Dorsch wrote: > Am Dienstag, 25. April 2023, 03:51:44 CEST schrieben Sie: > > I'd be interested to know if the issue persists on your system after > > upgrading. > > Yes, it repros always. OK. > -- System Information: > Debian Release: 12.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing-debug'), (105, > 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de:en_US I'm still not able to reproduce the issue. Today I was trying with the same locale as you (de_DE.UTF-8). I have seen issues in the past with certain locales -- typically in software that isn't careful enough and gets into trouble when a locale switches the period and comma in number formats. Even though I wasn't able to reproduce the problem here, it would be interesting if you can try with locale set to en_US for example: I have no idea where else to look. Given that no-one else has reported this, I'm leaning towards downgrading the severity to keep digikam in the upcoming release. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup
Hi Rainer, On Sun, 16 Apr 2023 09:38:07 +0200 Rainer Dorsch wrote: > Let me elaborate a somewhat: > > The spash screen bug I found is visible in the backtrace in comment 5: > > https://bugs.kde.org/show_bug.cgi?id=466170#c5 > > According to Maik, the bug is triggered by a race condition (comment 6). I.e. > even with exact the same software configuration, there is a good chance that > you don't see it, because the timing on your hardware might be different > (different CPU, memory latencies, cache configurations,). In particular > if > it is hard to hit the race condition, as it seems to be the case. That's fair. Is it hard for you to hit the race condition? > But the more important issue is the crash which I see after disabling splash > screen. The backtrace is provided in comment 7 Right, this is the one that concerns me more. A couple of days ago I thought I had reproduced the issue. But I can't reproduce it today. I think that either (a) I was mistaken the other day; or (b) updating the "testing" distribution fixed the bug. I did "apt upgrade" today before trying to investigate so unfortunately I can't tell which of the two possibilities is true. I'd be interested to know if the issue persists on your system after upgrading. > How do you generate this list? reportbug --template digikam > Do you know if I can disable the faces download? I don't know if that is possible. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup
Just a note to say that I have used a Debian "testing" chroot environment and can reproduce the reported crash. I will be investigating more in the coming days. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup
On Fri, 14 Apr 2023 14:24:31 +0200 Rainer Dorsch wrote: > Thanks Marco, that is a good link. > > I provided a backtrace and upstream acknowledged the bug to be fixed in 8.1.0: Hello Rainer, I've looked at the upstream bug, and all the information you provided. That's awesome -- I wish that every bug submitter would be as thorough as you! It seems that, even with disabling the splash screen, you still experience the bug -- is that correct? I can say that I'm not experiencing any such crash. I created a new user to test from scratch. I see the splash screen come and go, then the pop-up that offers to download the faces data files. I can download them or not and it all works fine either way. So it's puzzling. I'm also using an x64 system, but I run on the "sid/ unstable" distribution so I have slightly different versions of the dependency packages. Maybe it's worth attempting an upgrade of some or all of these to see if the problem goes away? Perhaps start with libkf5configcore5, since the failing assert seems to be in that library: qt_assert_x(char const*, char const*, char const*, int) () at /lib/ x86_64-linux-gnu/libQt5Core.so.5 Here is the list from my system today. Versions of packages digikam depends on: ii digikam-data 4:7.9.0-1 ii digikam-private-libs 4:7.9.0-1+b2 ii libc6 2.36-9 ii libgcc-s1 12.2.0-14 ii libkf5configcore5 5.103.0-2 ii libkf5coreaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libmagick++-6.q16-8 8:6.9.11.60+dfsg-1.6 ii libqt5core5a 5.15.8+dfsg-7 ii libqt5gui55.15.8+dfsg-7 ii libqt5sql55.15.8+dfsg-7 ii libqt5sql5-mysql 5.15.8+dfsg-7 ii libqt5sql5-sqlite 5.15.8+dfsg-7 ii libqt5widgets55.15.8+dfsg-7 ii libstdc++612.2.0-14 ii perl 5.36.0-7 Versions of packages digikam recommends: ii brave-browser [www-browser] 1.50.119 ii ffmpegthumbs4:22.12.3-1 ii firefox-esr [www-browser] 102.10.0esr-1 ii google-chrome-stable [www-browser] 112.0.5615.121-1 ii konqueror [www-browser] 4:22.12.3-1 ii lynx [www-browser] 2.9.0dev.12-1 ii w3m [www-browser] 0.5.3+git20230121-2 Versions of packages digikam suggests: ii breeze-icon-theme 4:5.103.0-1 pn digikam-doc ii systemsettings 4:5.27.2-1 Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1028163: sshfs-fuse bug
On Sunday, February 5, 2023 7:04:26 P.M. CST Santiago Vila wrote: > El 5/2/23 a las 21:54, Steven Robbins escribió: > > the test manifestly runs fine on buildds > > Actually, that's not really true. > > The tests do not even *run* on the buildds, because they are skipped. Indeed! I must have skipped over that output :-) But I think the larger point remains: there is no build failure in practice. What is different in your environment that makes it fail? -Steve signature.asc Description: This is a digitally signed message part.
Bug#1028163: sshfs-fuse bug
There are a couple of odd things about this bug. First: it doesn't seem like an RC bug because the test manifestly runs fine on buildds -- see https://buildd.debian.org/status/package.php?p=sshfs-fuse I'd suggest to downgrade the bug on this basis. Second: the bug log shows python 3.9.2 is used. That hasn't been the default python since 2021 -- so it's an unusual test environment. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1027965: Fix for the RC bug in vtk
Hello, Was looking yesterday for an RC bug to fix and noticed #1027965 against VTK -- a build failure in gdcm caused by missing dependency. The fix proposed by Mathieu seems reasonable to me. Anton: I'm writing to ask your opinion about the commits in salsa since the last upload (June 2022); specifically, do you feel they are suitable for inclusion now? Should I: 1. apply the patch to the lastest in salsa? 2. apply the patch to the last upload sources ignoring salsa? 3. leave it alone and let you deal with it? 4. something else? Appreciate your insight. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1019393: hdf5 breaks libsis-jhdf5-java autopkgtest: Could not initialize class
On Thu, 8 Sep 2022 16:11:33 +0200 Paul Gevers wrote: > With a recent upload of hdf5 the autopkgtest of libsis-jhdf5-java fails > in testing when that autopkgtest is run with the binary packages of hdf5 > from unstable. It passes when run with only packages from testing. I find the same holds for simple BUILDING of the libsis-jhdf5-java source package. The build succeeds when using libhdf5-dev from testing, but fails with the package from unstable. The failure happens when running tests. Below is output from first test failure. -Steve FAILED: testCreateVerifyContentArtificialRootRoundtripOK java.lang.ExceptionInInitializerError at hdf.hdf5lib.HDF5Constants.(HDF5Constants.java:29) at ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersion.(IHDF5WriterConfigurator.java: 74) at ch.systemsx.cisd.hdf5.IHDF5WriterConfigurator$FileFormatVersionBounds.(IHDF5WriterConfigurator.java: 127) at ch.systemsx.cisd.hdf5.h5ar.HDF5Archiver.(HDF5Archiver.java:112) at ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverFactory.open(HDF5ArchiverFactory.java: 41) at ch.systemsx.cisd.hdf5.h5ar.HDF5ArchiverTest.testCreateVerifyContentArtificialRootRoundtripOK(HDF5ArchiverTest.java: 330) at java.base/ jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java: 104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java: 100) at org.testng.internal.Invoker.invokeMethod(Invoker.java:646) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:811) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1129) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java: 129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java: 112) at org.testng.TestRunner.privateRun(TestRunner.java:746) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1264) at org.testng.TestNG.runSuitesLocally(TestNG.java:1189) at org.testng.TestNG.runSuites(TestNG.java:1104) at org.testng.TestNG.run(TestNG.java:1076) at org.testng.TestNG.privateMain(TestNG.java:1405) at org.testng.TestNG.main(TestNG.java:1374) Caused by: java.lang.UnsupportedOperationException: No suitable HDF5 native library found for this platform. at hdf.hdf5lib.H5.loadH5Lib(H5.java:240) at hdf.hdf5lib.H5.(H5.java:230) ... 28 more signature.asc Description: This is a digitally signed message part.
Bug#1016831: closed by Steven Robbins (Re: libminc: FTBFS on mipsel, mips64el)
On Mon, 22 Aug 2022 09:24:41 +0200 Sebastian Ramacher wrote: > > I can't reproduce this. The main difference between the one that built and the > > one that didn't is the new libc, so that's the most likely culprit. > > The 4th attempt on the buildds filed again: https://buildd.debian.org/status/ fetch.php?pkg=libminc=mips64el=2.4.03-5+b1=1661136219=0 > > Reopening. Please only close this bug when libminc is able to build on > the buildds again. I can't debug this! It builds OK in both the mipsel and mips64el chroots on porterbox eller. See https://lists.debian.org/debian-devel/2022/08/ msg00200.html Is there something broken on the buildd? -Steve signature.asc Description: This is a digitally signed message part.
Bug#1004628: qtav: FTBFS with ffmpeg 5.0
Heads up for those following this bug: qtav appears to be unmaintained upstream. My only interest in the package was to enable video playback in digikam. Digikam upstream has taken most of the qtav code, incorporated into digikam source tree and fixed it up. The next release of digikam will not need qtav and therefore I will no longer be maintaining qtav. The only other usage in Debian I can find is "matrix-mirage" (which is itself orphaned). My suggestion is to simply remove qtav from Debian. If you do need qtav for some other purpose, please respond here and consider yourself the new maintainer. Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#1004769: Video not handled anymore for now
On Sunday, July 17, 2022 4:09:20 A.M. CDT you wrote: > Le 16/07/2022 à 18:50, Steven Robbins a écrit : > > I would say that there may well be others in your situation so if you do > > find a method please report back to this bug. > >For my personnal use, until upstream provides a correct fix, I recompile > digikam 7.7.0-1 (-2 was not pushed in the git ;-) ) Now pushed, thanks! -Steve signature.asc Description: This is a digitally signed message part.
Bug#1004769: Video not handled anymore for now
On Friday, July 15, 2022 6:27:51 P.M. CDT you wrote: >Hi, > >This bug is rather anoying as I'm using digikam to manage my video. I agree it is annoying. I feel the same pain. Given the hard-transition of ffmpeg [1], it is not possible to build with video in unstable today. Digikam was temporarily removed from Debian and the only way to re-introduce it is to not use ffmpeg at all which has the serious side effect to drop video. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004831 > The low severity (and the title of the bug) does not allow one to stop > the upgrade with apt-listbugs. In my opinion, this bug is at lease > important (to be seen by apt-listbugs) and its title should reflect > that video is not handle by digikam for now (or a new bug can be > created and blocked by this one) Thank you for the suggestion. I was completely unaware of "apt-listbugs". I have just re-titled and changed the severity of this bug. The manpage for apt-listbugs says it displays serious and above by default. Therefore, I have made it 'serious' according to the criteria "in the package maintainer's or release manager's opinion, makes the package unsuitable for release". >Due to the large dependencies, it is probably very difficult to > downgrade digikam to a version with video support once 4:7.7.0-1 > is installed. I did not try for now. I haven't tried either, so I don't know. Maybe one can just pull the packages from the last stable release? Build the 7.6 source package ? I would say that there may well be others in your situation so if you do find a method please report back to this bug. > I hope video will be soon back. Upstream is certainly aware of the issue and work is underway to migrate to the newer ffmpeg. I am monitoring the upstream mailing list and sources. Based on what I see at present, I'm not optimistic for the short term, so if you're using testing or unstable you may want to look into the downgrade option. I am more hopeful that things will be resolved in time for the next Debian release. Best, -Steve
Bug#1004769: digikam: FTBFS with ffmpeg 5.0
control: severity -1 normal On Fri, 25 Feb 2022 22:55:12 +0100 Sebastian Ramacher wrote: > On 2022-02-21 16:05:37 -0600, Steven Robbins wrote: > > On Tue, 1 Feb 2022 21:01:39 +0100 Sebastian Ramacher > > wrote: > > > Source: digikam > > > Version: 4:7.1.0-2 > > > > I have just uploaded Digikam 7.5.0 to unstable. If you have a chance to re- > > try the build, would appreciate knowing if it now builds with new ffmpeg. > > 7.5.0 fails to build with the same error. I have temporarily disabled video player in Digikam 7.7.0-1 upload, so lowering this bug severity. -Steve signature.asc Description: This is a digitally signed message part.
Bug#1011051: libssl3: upgrade to libssl3 broke my dovecot setup
On Monday, June 6, 2022 6:11:38 A.M. CDT Bernhard Übelacker wrote: > The recent dovecot upload contains this fix: > >dovecot (1:2.3.19+dfsg1-1) unstable; urgency=medium > * [d223bbd] d/patches: add patch to support openssl 3.0 (Closes: > #996273) > > > https://salsa.debian.org/debian/dovecot/-/commit/d223bbd1d0968ad2b46c4316c1 > 02c11bde8c5075 That's good news. Does it mean one can remove the workaround (commenting out "providers = provider_sect") ? Regards, -Steve
Bug#1010057: digikam: Failed when generated data-base
On Saturday, April 23, 2022 7:23:48 A.M. CDT Hoareau Jean Pierre wrote: > Package: digikam > Version: 4:7.6.0-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > I installed Debian "Bookworm" in order to test this version. When launching > "Digikam" I get a database loading/generation error. Are you using an external DB like mysql/mariadb? Does the workaround in this report help? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007220 If not, can you provide reproduction steps? Digikam 7.6.0 works for me so the reproduction will need explicit configuration steps. Maybe you can configure from scratch for a new folder and share those steps? Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#984063: [Debian-med-packaging] Bug#984063: Closing bug (Was: Bug#984063: itk libtiff test issues (Was: Bug#984063))
On Saturday, January 22, 2022 12:15:25 P.M. CST Étienne Mollier wrote: > Hi Andreas, > > Andreas Tille, on 2022-01-16: > > I think the roadmap that ITK4 will be deleted as soon as possible > > is clear. However, if it might serve as an intermediate means > > to support some remaining dependencies temporarily I think it > > is OK to do some tricks that would not be acceptable as long > > term means. > > I have been working on a rewrap of insighttoolkit4 to include > the embedded tiff library, and with all the previous patching to > address the initial issue described in this bug, the build went > through. The package should be in shape for upload tomorrow. Neat! I'm sure that those using ITK 4 will appreciate your work. As far as the existing Salsa repository is concerned: I would encourage you to consider using a v4 branch to maintain it. If you prefer to do something else, that is also fine with me. Just want to be clear that I haven't any objection to keeping v4 and v5 in a single repository. -Steve signature.asc Description: This is a digitally signed message part.
Bug#984063: itk libtiff test issues (Was: Bug#984063)
On Saturday, December 11, 2021 3:02:02 A.M. CST Étienne Mollier wrote: > I considered pushing a change yesterday to disable those tests > on insighttoolkit4, Let's please agree to NEVER do that. > not to hide dust under the carpet, but to > give a chance to reverse dependencies to make it to testing in a > decent enough shape hopefuly. I appreciate the sentiment, but medical & scientific software -- probably the only consumers of ITK -- is generally the sort that you never want to knowingly ship with failed tests. -Steve signature.asc Description: This is a digitally signed message part.
Bug#984063: Please lets coordinate itk4/itk5 issues (Was: Bug#984063)
On Monday, November 8, 2021 1:09:43 A.M. CST Andreas Tille wrote: > Hi, > > this mail from Jose > > Am Sat, Nov 06, 2021 at 01:33:29AM +0100 schrieb Jose Luis Rivero: > > Hello! Gazebo maintainer here, affected by this RC bug. Looking into > > upstream repository there is a potential commit that can be used to patch > > this problem until new versions land in Debian: > > > > https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359 > > a8fdb55304124823a3a8c9 Are you saying this will allow ITKv4 to be built with current gcc? At present, ITK is about to be removed from testing tomorrow because it won't build. > caused me having a look into the Git repository of insighttoolkit4[1]. > It is missing the NMU 4.13.3withdata-dfsg1-4.1 by Andreas Beckmann and > there are now the first commits done by Steve for insighttoolkit5 > version 5.2.1 which was ITPed by Ghislain[2]. Yep, I've already uploaded ITK 5 to Debian. https://ftp-master.debian.org/new/insighttoolkit5_5.2.1-1.html > I think we need to discuss whether > > 1. We want to simply replace insighttoolkit4 (which makes the > usage of the existing repository[1] sensible - but please inject > the NMU changes at least in d/changelog Yes. This is what I've communicated already 2-3 times on the list -- going back a year -- and in Ghislain's ITP. https://lists.debian.org/debian-med/2020/11/msg00212.html https://lists.debian.org/debian-med/2021/10/msg00149.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995829#10 > 2. We should start ITK5 in a new repository and maintain both > versions at least for some time in parallel until all packages > that currently use ITK4 are migrated. If we can get ITK4 to build with current compilers, my suggestion would be to make a v4 branch in the current repository. On the other hand, it's kind of 11th hour here. I'm much more focused on replacing v4 with v5 -- which, to be fair is already more than two years old. ITK v4 is no longer supported upstream. > In any case people who are interested in ITK should coordinate their > work and talk to each other which I'd like to kindly invite you to > do here on the Debian Med mailing list (any other channel is fine for > sure). Yes, I've always used debian-med for communications. Additional hands are always welcomed. -Steve signature.asc Description: This is a digitally signed message part.
Bug#994419: libgtest-dev: missing dependency on libgmock-dev
On Thursday, September 16, 2021 1:07:19 A.M. CDT you wrote: > Sorry for the confussion, that also refers to fastcdr, which has a > failing autopkgtest here: > https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15272003/log. > gz So it looks like gtest 1.11.0 may well have fixed it. There's a passing test now: https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15289175/ log.gz -Steve signature.asc Description: This is a digitally signed message part.
Bug#994419: libgtest-dev: missing dependency on libgmock-dev
On Thursday, September 16, 2021 1:07:19 A.M. CDT you wrote: > * Steven Robbins [2021-09-15 20:52]: > >I thought this tag was for the case that the package fails to build from > >source. ?? https://www.debian.org/Bugs/Developer > > I thought this is also transitively for FTBFS caused in other > packages, but I might be wrong on this. Feel free to adjust the tags > if you think it is mislabeled. Well, Adrian Bunk chimed in saying it is used "in practice" transitively. But that's the first I've heard of it and contrary to what the cited doc says. So I prefer to remove the tag. > >> I just noticed that this bug not only breaks autopkgtest > > > >What autopkgtest? I don't think googletest has one. > > Sorry for the confussion, that also refers to fastcdr, which has a > failing autopkgtest here: > https://ci.debian.net/data/autopkgtest/testing/amd64/f/fastcdr/15272003/log. > gz > >I can't reproduce this. I used "apt source fastcdr" to get the 1.0.21-2 > >sources and they built fine. > > Did you use the latest CMake version from unstable, i.e. CMake > 3.21.2? I'll attach a build log from my pbuilder sid chroot. The > relevant failure occurs at line 698. Thanks for this. It turns out that my mirror still has cmake at 3.18.4-2. Also I realise now I was testing on a system that had both libgtest-dev and libgmock-dev installed -- so I wouldn't have triggered it anyway. Will test properly tonight. Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#994419: libgtest-dev: missing dependency on libgmock-dev
On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote: > Control: tags 994419 + ftbfs I thought this tag was for the case that the package fails to build from source. ?? https://www.debian.org/Bugs/Developer > I just noticed that this bug not only breaks autopkgtest What autopkgtest? I don't think googletest has one. > but also causes fastcdr to FTBFS. I can't reproduce this. I used "apt source fastcdr" to get the 1.0.21-2 sources and they built fine. Can you provide explicit instructions on reproducing the issue, please? Best, -Steve
Bug#994419: libgtest-dev: missing dependency on libgmock-dev
On Wednesday, September 15, 2021 2:25:49 P.M. CDT Timo Röhling wrote: > Package: libgtest-dev > Version: 1.10.0.20201025-1.1 I've discovered that upstream has released 1.11 -- which I'll package up. > the GTestTargets.cmake that is shipped in libgtest-dev also exports > the GTest::gmock and GTest::gmock_main targets. However, the > corresponding libraries libgmock.a and libgmock_main.a are shipped > in libgmock-dev. This causes a fatal error and prevents successful > CMake configuration in dependent projects. Do you have a minimal reproduction by any chance? I'd like to test out 1.11 -- just in case it fixes the problem. Thanks, -Steve
Bug#994419: libgtest-dev: missing dependency on libgmock-dev
On Wednesday, September 15, 2021 2:48:01 P.M. CDT Timo Röhling wrote: > > Please add Depends: libgmock-dev to libgtest-dev. > > I just noticed that this bug not only breaks autopkgtest but also > causes fastcdr to FTBFS. > > In case you're wondering, apparently this bug has been exposed by > the changes in the new CMake version that has hit unstable, so this > will possibly affect more packages. Intriguing. Note that gtest is intended as the base layer (gmock is built on top of gtest), so it would be a loss to have libgtest-dev pull in gmock. Hopefully there's an alternative fix. -Steve signature.asc Description: This is a digitally signed message part.
Bug#992854: digikam: symbol lookup error: undefined symbol: FT_Palette_Select
On Tuesday, August 24, 2021 4:32:33 A.M. CDT Alain Bertrand wrote: > > Launching digikam > digikam: symbol lookup error: > /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5: undefined symbol: > FT_Palette_Select and digikam exits I have not encountered this myself. A quick google suggested possibly an issue with freetype library -- see https://bbs.archlinux.org/viewtopic.php?id=259420 What is output of ldd /usr/bin/digikam |grep -i freetype ? What freetype package/version is installed? Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#976037: marked as pending in ms-gsl
On Saturday, December 26, 2020 8:35:08 A.M. CST Nicholas Guriev wrote: > I have rewritten auto-tests, so they do not longer require non-default > versions of compilers. Since the tests with GCC rely on the same version > of the compiler that built Google Test framework, I think preconditions > of Bug#972944 lose its relevance, and there is no need to rebuild the > googletest from sources (in /usr/src/googletest). > > Steve Robbins, am I right in my judgments? I believe there remain some corner cases where the build options of the software under test may not precisely match those used in building googletest -- leading to compile or test failures. One example is described in bug #789267. That said, many projects do indeed successfully use the compiled library. So you are probably fine. If you encounter odd failures, you can always revert back to building gtest. Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#974011: xmille: Incorrect license/copyright for xmille
On Saturday, December 26, 2020 12:50:58 A.M. CST Keith Packard wrote: > I've tagged version '1.0' of this repository and created some (not > finished) debian packaging for it. This version has imported the mille > sources from 'upstream' which include copyright information for the > BSD-sourced files. > > How would you like to go about getting these 'xmille' bits into the > archive as a replacement for the ancient bits now living there? Personally speaking: if you're already working on debian packaging, my preference is to just step aside and let you carry on. If you're willing, then I think it mainly becomes a problem of what to name the source package as the new sources are more than just xmille. I don't mind co-maintaining but, realistically, I won't be much help. If you are NOT interested in maintaining the package, then I can continue. Unless Adrian wants to do it? ;-) Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#974011: xmille: Incorrect license/copyright for xmille
On Sunday, December 20, 2020 9:44:46 A.M. CST Adrian Bunk wrote: > On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote: > > Adrian Bunk writes: > > > Keith, do you remember the copyright history of this code? > > > > I may have copied the underlying mille sources *before* copyrights were > > added to each file; I started work on the X10 version of xmille around > > 1985 or 1986. I guess I could have mistakenly removed them? Thanks for > > discovering this error; I can fix these "upstream" and publish a new > > version? > > I am just a user who would like to see this package also in bullseye. > > A new upstream version would be good, but it is not obvious to me > whether you or Steve M. Robbins or anyone else is considered upstream > or should become upstream (again). Upstream is definitely NOT me ! :-) signature.asc Description: This is a digitally signed message part.
Bug#977473: Would you mind updating insighttoolkit4
On Tuesday, December 15, 2020 11:10:32 A.M. CST Andreas Tille wrote: > Hi again, > > sorry, I intended to respond to bug #977473 as well which really should > be dealt with, I had a look and can reproduce the build error. (in fact my local build had more than just the one failure) But this is a failure in in a test of the python wrapping of GDCM that passed the previous build -- with unmodified ITK sources/ I lack the time and motivation to debug this kind of issue. Sorry, but I will pass on this. -Steve signature.asc Description: This is a digitally signed message part.
Bug#952599: fixed in insighttoolkit4 4.13.2-dfsg1-7
>[ Steve Robbins ] >* Update build-dep from swig3.0 --> swig3. Closes: #952599. This is a typo: the build-dependency is just "swig", which is presently swig 4. -Steve signature.asc Description: This is a digitally signed message part.
Bug#952599: marked as pending in insighttoolkit
Control: tag -1 pending Hello, Bug #952599 in insighttoolkit 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/med-team/insighttoolkit/-/commit/82fbfd7a0e1c63c76a84c956e49cc7db9cc20f13 Update build-dep from swig3.0 --> swig3. Closes: #952599. (this message was generated automatically) -- Greetings https://bugs.debian.org/952599
Bug#952426: digikam: digkam experimental not correctly instalable
Eric, Thank you for the bug report. Per your question: I do indeed test before uploading -- I've been using Digikam 7 since I uploaded last week. On Monday, February 24, 2020 4:38:40 A.M. CST Eric Valette wrote: > valette@tri-yann4:~$ digikam --version > digikam: error while loading shared libraries: libhdf5_serial_hl.so.100: > cannot open shared object file: No such file or directory Thanks. Before today, I thought the issue was merely a missing dependency. On my system, digikam works with libhdf5 installed so I thought it would for you as well. Here's what I see: $ digikam --version digikam 7.0.0-beta2 $ ldd /usr/bin/digikam |grep libhd libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fb5136e5000) libhdf5_serial_hl.so.100 => /lib/x86_64-linux-gnu/ libhdf5_serial_hl.so.100 (0x7fb510895000) I think your issue may be due to attempting to use the experimental version of libhdf5. I'm using hdf5 from unstable. Note that the buildd pulls all its dependencies from unstable; e.g. Get: 705 https://mirrors.wikimedia.org/debian unstable/main i386 libhdf4-0-alt i386 4.2.14-1 [285 kB] Get: 706 https://mirrors.wikimedia.org/debian unstable/main i386 libsz2 i386 1.0.4-1 [6820 B] Get: 707 https://mirrors.wikimedia.org/debian unstable/main i386 libhdf5-103 i386 1.10.4+repack-10 [1310 kB] -- from i386 build log https://buildd.debian.org/status/fetch.php? pkg=digikam=i386=4%3A7.0.0%7Ebeta2%2Bdfsg-1=1582008391=0 Can you try using deps from unstable and let us know how it goes? Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)
On Sunday, February 23, 2020 2:32:49 P.M. CST John Scott wrote: > On February 23, 2020 3:11:46 PM EST, Marco Bodrato wrote: > >Ciao, > > > >Il Dom, 9 Febbraio 2020 9:34 pm, Steven Robbins ha scritto: > >> On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote: > >It seems to me that all packages incorrectly using the internal > >representation and not the documented interface of GMP where patched. > > > >What else stops migration of GMP to testing? Maybe a release of GMP > > > >explicitly saying that it breaks: > > libmath-gmp-perl < 2.20 > > libmath-prime-util-gmp-perl < 0.51-2 > > postgresql-pgmp < 1.0.4 > > > >is needed? So that nobody will update the library without updating also > >the other possibly failing packages? > > > >Ĝis, > >m > > GMP is not migrating because this bug was marked as done by uploading > postgresql-pgmp. However, this bug is filed against GMP, so the bug > metadata still suggests that GMP 6.2.0 introduces this serious issue. Right. I have tried twice to close the bug, with no apparent effect. Perhaps with Marco's suggestion of a new upload containing specific breaks will let me close it against a new revision of gmp. -Steve signature.asc Description: This is a digitally signed message part.
Bug#951003: libmath-gmp-perl: FTBFS with gmp 6.2.0: test failure
On Sun, 09 Feb 2020 18:04:33 +0100 gregor herrmann wrote: > Source: libmath-gmp-perl > Version: 2.19-1 > Severity: serious > Tags: upstream ftbfs sid bullseye > Justification: fails to build from source (but built successfully in the past) I created a minimal pull request for this: https://salsa.debian.org/perl-team/modules/packages/libmath-gmp-perl/ merge_requests/1 -Steve signature.asc Description: This is a digitally signed message part.
Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)
On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:
> Ciao,
>
> From
> https://ci.debian.net/data/autopkgtest/testing/arm64/libm/libmath-gmp-perl/4
> 229384/log.gz I read the following:
>
> # Failed test 'Test worked: $x =
> Math::GMP->new("387047");Math::GMP::probab_prime($x,25);'
> # at t/01_gmppm.t line 192.
> # got: '2'
> # expected: '1'
>
>
> From the manual of GMP
> https://gmplib.org/manual/Number-Theoretic-Functions.html I read the
> following:
>
> Function: int mpz_probab_prime_p (const mpz_t n, int reps)
> Determine whether n is prime. Return 2 if n is definitely prime,
> return 1 if n is probably prime (without being certain), or return 0 if
> n is definitely non-prime.
>
> So, if the new release of the library is able to answer that the number
> 387047 is prime, and not only "probably" prime... This should not be
> marked as a regression...
Indeed! Thanks for investigating. An improvement could be simply that all
tests of this function (and any similar?) should be written to expect non-
zero, rather than superficially 1 or 2.
Is there a bug for libmath-gmp-perl for this test suite issue?
Best,
-Steve
signature.asc
Description: This is a digitally signed message part.
Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)
Hello Christoph, On Thursday, February 6, 2020 3:43:41 A.M. CST Christoph Berg wrote: > Re: Steven Robbins 2020-02-06 <4839510.uz11uGdL23@riemann> > > > > the new gmp version makes postgresql-pgmp crash on arm64: > > > > > > https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/ > the postgresql-pgmp author found a fix so this isn't an issue anymore: > > https://github.com/dvarrazzo/pgmp/issues/18 > https://github.com/dvarrazzo/pgmp/commit/04274c40b63d3dff758bee47c8525112d64 > d1ab2 > > I don't know the gmp internals, but I guess this fix might be > applicable to other gmp users as well if they have problems. Thank you! This is very helpful -- there are three other autopkgtests failing with GMP 6.2 (packages in cc). Maybe these are also triggered by a change in GMP: https://gmplib.org/list-archives/gmp-announce/2020-January/48.html Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#950608: gmp 6.2.0 crashes postgresql-pgmp
On Tue, 4 Feb 2020 09:23:34 +0100 Christoph Berg wrote: > Hi, > > the new gmp version makes postgresql-pgmp crash on arm64: > > https://ci.debian.net/data/autopkgtest/testing/arm64/p/postgresql-pgmp/ 4173638/log.gz > (linked from https://packages.qa.debian.org/g/gmp.html) ...etc. Thanks, that's useful to know. I don't know the postgresql-pgmp code at all. Can you help me understand what the linked web pages are telling us? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
