Much appreciated, Craig!
I started using zfs a year ago and was naively thinking that the Debian
package system somehow "handled" things. I see that is not the case. What
can be done better?
On Sunday, December 8, 2024 7:53:03 P.M. CST Craig Sanders wrote:
> If you use ZFS (or ANY other n
On Saturday, December 7, 2024 3:44:43 P.M. CST you wrote:
> The build log shows a warning: "kmem_cache_create" redefined so I suspect an
> upstream fix is required.
I completely misread the build log. The kmem_cache_create diagnostic is only
a warning. The actual build error is something else:
Control: reassign 1085429 ms-gsl
On Thursday, October 31, 2024 4:08:45 A.M. CDT Sylvestre Ledru wrote:
> Control: reopen 1085429
>
> Hello
>
> I am sorry but it needs to be workaround. it is still happening and
> blocking the llvm 19 migration
Fair enough, but it's not a bug in googletest. Su
On Sunday, October 27, 2024 2:16:20 A.M. CDT Andrey Rakhmatullin wrote:
> On Sat, Oct 26, 2024 at 04:29:17PM -0500, Steven Robbins wrote:
> > Hello,
> >
> > On Saturday, October 26, 2024 2:20:05 P.M. CDT Andrey Rakhmatullin wrote:
> > > Control: reassign -1 libgt
Hello,
On Saturday, October 26, 2024 2:20:05 P.M. CDT Andrey Rakhmatullin wrote:
> Control: reassign -1 libgtest-dev 1.15.2-1
> Control: affects -1 libmsgsl-dev
> That macro in libgtest-dev indeed contains a switch statement without a
> default label, reassigning.
The code in question is test co
On Mon, 5 Aug 2024 10:01:33 -0400 Jeremy Bícha
wrote:
> Control: tags -1 +pending
> Control: severity -1 serious
>
> Steve, could you do the ipe-tools upload now? I am ready to do the
> poppler 24.08 transition once the Debian Release team is ready.
Just pushed the upload.
Thanks!
-Steve
sign
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 promo
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 +
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
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.
U
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.
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 digit
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
ri
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.
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/d47841b9d2d96c47a
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 cont
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
> Usert
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
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 depend
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
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 encoun
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
>
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 (comm
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.
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 e
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 skip
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
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);
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 f
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/s
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 wil
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 p
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
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.
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
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 databas
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
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 t
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
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. T
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
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 auto
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 GTe
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
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 poss
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 B
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 fi
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 wer
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
>[ 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.
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/82fbfd7a0e1c63c76a
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 lib
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
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
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
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/auto
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
57 matches
Mail list logo
