Bug#1040960: gcc-sh-elf fix is on the way
Control: owner -1 John Scott Control: tags -1 pending I made a boo boo. An explanation and fix will be ready shortly signature.asc Description: This is a digitally signed message part
Bug#1042935: Sage test timeouts probably fixed upstream
Control: tags -1 fixed-upstream Control: block -1 by 1010735 I think this is fixed upstream. Apparently they were made aware that this particular failing test just takes a long time, but if you give it a couple minutes it does pass. signature.asc Description: This is a digitally signed message part
Bug#1037904: Xournal++ GCC 13 FTBFS fixed upstream
Control: forwarded -1 https://github.com/xournalpp/xournalpp/commit/9172ee831f4dfbb88dfeb13b66862e80e64a0d3f Control: tags -1 fixed-upstream It looks like this has been fixed upstream, so I'm setting the bug metadata as such. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1031439: gcc-sh-elf FTBFS: mystery solved?
Hi, I'm doing the build right now and it got past the part where it's been failing, so I'm pretty sure we're good! Adrian, would you be willing to sponsor my upload? I'll send a second mail when it's ready. The change is extremely small, and to be frank I'll probably skip running the test suite, but I believe the software will be sound. signature.asc Description: This is a digitally signed message part
Bug#1024626: Blender removal for 32-bit architectures
Hi, I see from previous mails that Blender upstream has decided not to support 32-bit architectures anymore. This is a friendly ping that the maintainer will request its removal so it may migrate into Bookworm. Thanks, John signature.asc Description: This is a digitally signed message part
Bug#997767: open-ath9k-htc-firmware: FTBFS: patching fails
The fix is currently waiting in the NEW queue. signature.asc Description: This is a digitally signed message part
Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614
On Thu, 2021-09-30 at 09:18 -0400, John Scott wrote: > Outside a minimal chroot, on my desktop system, zbarimg seems to > process SVGs just fine. So this may be a case of a Recommends > (somewhere) not being installed wreaking havok, but in my opinion > zbarimg should still not behave this way when a Recommends is > missing. I've found the culprit: if libmagickcore-6.q16-6-extra is not installed, then this cryptic error occurs. I've reported this issue (the lack of a helpful error message) at https://github.com/mchehab/zbar/issues/202 . I'll leave it to the maintainer to decide what they'd like to do: either hardcode a dependency on libmagickcore-6.q16-6-extra, or switch zint's output format to PNG (I personally would prefer the latter). signature.asc Description: This is a digitally signed message part
Bug#995362: zint breaks zbar autopkgtest: unable to open file `/tmp/magick-VxkNk3KeW43pSnBYixIpsF9xU8qRmIzE': No such file or directory @ error/constitute.c/ReadImage/614
Control: reassign -1 zbar-tools Control: notfound -1 zint/2.10.0-1 Control: owner -1 ! I think I've partially identified what is happening. It turns out that the version of zint in testing, despite being passed the --filetype=SVG flag, actually produces a PNG, which in the past has been happily processed by zbar. This bug in zint seems to have been fixed in the new version, so that specifying --filetype=SVG actually produces an SVG now. And it appears that the error is coming from zbarimg, which as a matter of fact gives the same error in a minimal chroot trying to process any SVG. Outside a minimal chroot, on my desktop system, zbarimg seems to process SVGs just fine. So this may be a case of a Recommends (somewhere) not being installed wreaking havok, but in my opinion zbarimg should still not behave this way when a Recommends is missing. I'll debug this more later, but for now I'm reassigning the bug to zbar-tools, since I see this is not an issue in zint. signature.asc Description: This is a digitally signed message part
Bug#992689: dino crashing with new gnome 40
On Sun, 2021-08-22 at 13:43 -0400, Taowa wrote: > I'm planning on doing an upload this week to fix it- ideally today. Do you still got this, Taowa? signature.asc Description: This is a digitally signed message part
Bug#978793: dnssec-trigger: ftbfs with autoconf 2.70
Hey Matthias, > checking for library containing inet_pton... none required > checking for library containing socket... none required > checking for GNU libc compatible malloc... yes > configure: error: cannot run /bin/sh ./config.sub Can you double-check this/run a rebuild and see if it was a spurious issue? I'm not the maintainer, just a wandering passerby, but it seems dnssec-trigger's configure script builds and works just fine with Autoconf 2.71. I can't explain the error from your log with being unable to run config.sub, but it doesn't occur on my system and dnssec-trigger builds successfully. signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: addressing for Bullseye & newcomer suggestions
On Wed, 09 Jun 2021 00:32:02 + John Scott wrote: > I believe it's in the best interest of Debian users that this bug be > downgraded for Bullseye so Sage can be used in the mostly-wholesome > shape it's in, but since I lack expertise in maintaining it I too > will leave this to someone else. If you're looking for someone that can be committed to fixing issues in SageMath for the duration of the stable release cycle, I think I can step up to the plate, with the caveat that I will have to learn as I go since I don't yet know Python, but would like to learn and could seize this opportunity. (C is my forte, so perhaps I can help with some dependencies.) I've sent a merge request to add a superficial autopkgtest checking that 'sage -v' works, as it has broken in the past, and would appreciate if it could be merged (I believe this is appropriate during the freeze): https://salsa.debian.org/science-team/sagemath/-/merge_requests/14 Please let me know if there is any other low-hanging fruit I could work on as a newcomer to get acquainted with the package. signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: how to address for Bullseye
On Tue, 08 Jun 2021 17:15:44 +0200 Julien Puydt wrote: > I've been convinced that getting a fragile sagemath in next stable > wouldn't be a good thing. You've put much more effort than I have into maintaining scientific software in Debian, so I respect your opinion, but is it really accurate to say that SageMath is fragile as a whole? With respect to this particular issue, I'd like to share my perspective wrangling with a package that poses a similar dilemma: GCC (I'm working on packaging gcc-sh-elf). Like the status quo with SageMath in Debian, GCC has a test suite where failures are normal, and in general it takes an individual to watch out for what number of failures counts as "too many." Rather than hardcode an arbitrary threshold for what number of failing tests is acceptable, it seems that it's much better, and in the interest of Debian ports and alternative build environments, to just let the tests run for informative purposes. This, I believe, is what the GCC team actually does; the test results get sent to the team mailing list IIRC. Perhaps we should take a similar philosophy towards the tests. At least with GCC and DejaGnu, the test results get written out to a file, so before a new upload, say, one can do a diff on the old and new test results and see if any new regressions were introduced. In this same respect, SageMath test results may be best consulted before new uploads by hand. I believe it's in the best interest of Debian users that this bug be downgraded for Bullseye so Sage can be used in the mostly-wholesome shape it's in, but since I lack expertise in maintaining it I too will leave this to someone else. signature.asc Description: This is a digitally signed message part
Bug#986527: sagemath: FTBFS: /<>/sage/src/bin/sage: line 549: exec: cython: not found
Has anyone been able to reproduce this? Attempting to build Sage in a fresh unstable environment succeeds for me; perhaps the build failure was spurious. signature.asc Description: This is a digitally signed message part
Bug#980211: libextractor: FTBFS (flaky tests)
On Wed, 10 Feb 2021 21:02:47 +0100 Bertrand Marc wrote: > Indeed, the original issue reported in this bug was fixed in 1.11-1. > However, the general issue of flaky tests is still there: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libextractor.html > > Would you consider this bug as fixed? I hadn't seen the failure at reproducible builds; indeed that's not looking good. I've built libextractor about a dozen times and can't reproduce the test_html failure. Perhaps it happens so seldom that it won't happen on a buildd, or is specific to the Reproducible Builds environment. I personally regard the issue fixed, since the original issue was mitigated and the test_html failure seems to be within other margins of failure. Usually a second build is tried before an FTBFS bug is warranted, and none of the applicable dependencies have had any change. Note that the bug submitter was not filing a conventional FTBFS on behalf of QA or the Release Team, but instead was concerned with the librpm9 transition. Let me know if there's anything particular I can do to help, and thanks for your careful maintainership. signature.asc Description: This is a digitally signed message part
Bug#980211: libextractor: FTBFS (flaky tests)
According to upstream, the fix for this should've been included in the 1.11-1 upload. Can this issue be closed? signature.asc Description: This is a digitally signed message part.
Bug#980592: clamav: FTBFS: check_jsnorm.c:250:57: error: format not a string literal and no format arguments [-Werror=format-security]
Control: tags -1 patch fixed-upstream Control: forwarded -1 https://github.com/Cisco-Talos/clamav-devel/commit/18306 I found that the build succeeds with the upstream patch. It seems like ck_assert_msg() was missing an argument. signature.asc Description: This is a digitally signed message part.
Bug#976566: opencolorio: FTBFS: Imath.h:13:10: fatal error: OpenEXR/OpenEXRConfig.h: No such file or directory
To fix this on amd64 it's sufficient to add libopenexr-dev as a build-dep. signature.asc Description: This is a digitally signed message part.
Bug#972936: libgcc-s1-dbgsym is Protected: yes
On Thursday, October 29, 2020 9:08:12 AM EST Julian Andres Klode wrote: > My suggestion is to set XB-Important: yes and Protected: yes on > libgcc-s1 such that people cannot easily remove it after it's installed. This has migrated to testing and is having an unexpected consequence for me: > WARNING: The following essential packages will be removed. > This should NOT be done unless you know exactly what you are doing! > libgcc-s1-dbgsym > > 96 upgraded, 3 newly installed, 3 to remove and 0 not upgraded. > Need to get 519 MB of archives. > After this operation, 600 MB disk space will be freed. > You are about to do something potentially harmful. > To continue type in the phrase 'Yes, do as I say!' It really is the case that the dbgsym is marked Protected: yes. What package would this bug be in? dpkg or debhelper? P.S. In your last mail you put > Control: subscribe -1 Did that command actually work? It's not documented. https://www.debian.org/Bugs/server-control signature.asc Description: This is a digitally signed message part.
Bug#954189: Upload approval for acmetool 0.2 in buster-backports
On Thursday, August 6, 2020 6:38:33 PM EDT Ralph Giles wrote: > I wanted to request approval from the maintainer team to upload the > acmetool 0.2.1-2 package currently in testing/unstable to buster- > backports. > > The version currently in buster (0.0.63) only supports the deprecated > ACME v1 protocol, which no longer works for new registrations, and will > stop working even for renewals in 2021. As such, the package isn't > usable for deploying new sites on buster installs. Backports is for Shiny New Stuff. Release-critical bug fixes, especially low- risk ones, should always go to stable-updates. Also just as a technicality, ACME v1 only no longer works for Let's Encrypt. Other certificate authorities to the best of my knowledge may choose to keep supporting ACME v1. In this way the package is not totally unusable. signature.asc Description: This is a digitally signed message part.
Bug#969360: Qt seccomp failure patch works
Control: tags -1 - fixed-upstream On Wednesday, September 2, 2020 8:02:42 AM EDT Dmitry Shachnev wrote: > My guess is that we need this patch (not applied upstream yet) Thanks for the pointer, that patch applies cleanly and fixes the issue. > But that bug (QTBUG-81313) is already fixed in Qt 5.14.2. So we are > probably seeing something else. I saw that and figured it might've been a mistake on their part. It's even the same syscalls that are failing the issue's so similar, but perhaps their fix was incomplete. signature.asc Description: This is a digitally signed message part.
Bug#969360: Qt seccomp failure fixed upstream
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-81313 Control: tags -1 upstream fixed-upstream It turns out it is a clash both with Chromium (powers Qt WebEngine) and glibc. Check out the Red Hat bugs https://bugzilla.redhat.com/show_bug.cgi?id=1812482 (Qt) https://bugzilla.redhat.com/show_bug.cgi?id=1773289 (Chromium) The Chromium package also doesn't work on i386; that's bug #965960. signature.asc Description: This is a digitally signed message part.
Bug#967143: Python3 update
Control: unblock -1 by 937695 937569 Control: block 937695 by -1 Control: block 937569 by -1 Control: merge -1 936632 > I have reached out to the gnumeric folks; they say a new version > including python3 support should be out in a couple of months. Thanks! Your citing the removal from Debian must've got their attention. They just released version 1.12.48 which should have the fixes. signature.asc Description: This is a digitally signed message part.
Bug#936783: kcachegrind: Python2 removal in sid/bullseye
Python 3 doesn't include hotshot, so the hotshot2calltree script should be dropped. Upstream still includes it but it doesn't appear to have seen any maintenance: https://invent.kde.org/sdk/kcachegrind/-/tree/master/converters signature.asc Description: This is a digitally signed message part.
Bug#940017: crypto-policies: Incomplete debian/copyright?
On Wednesday, September 11, 2019 4:03:59 AM EDT Chris Lamb wrote: > I just ACCEPTed minder from NEW but noticed it was missing attribution > for at least Tomáš Mráz. This bug is against crypto-policies, but it appears you accepted minder too the same day. Did you mean to file this against minder? signature.asc Description: This is a digitally signed message part.
Bug#959599: frama-c: FTBFS fixed upstream
Control: forwarded -1 https://lists.gforge.inria.fr/pipermail/frama-c-discuss/2020-June/005823.html Control: tags -1 fixed-upstream > Hello, > > Le jeu. 4 juin 2020 à 18:43, John Scott a écrit : > > I'm not the maintainer, just a prospective user taking a look, but Frama-C > > hasn't been building from source in a while [1] and I couldn't find a bug > > for > > it. It fails with > > File "src/plugins/wp/ProverWhy3.ml", line 131, characters 29-45: > > 131 | Why3.(Term.t_const Number.(const_of_big_int (BigInt.of_string > > (Z.to_string z Why3.Ty.ty_int > > Error: Unbound value const_of_big_int > > Thanks for the report. There is indeed a compatibility issue between > Frama-C 20.0 and Why3 1.3, which is fixed in the upcoming Frama-C 21.0 > (currently available in beta) On the other hand, Frama-C 21.0 won't be > compatible with Why3 < 1.3 I'm having trouble finding their VCS and what commit fixed this, but updating Frama-C to the beta should be sufficient. Unstable and testing already have Why3 >= 1.3. signature.asc Description: This is a digitally signed message part.
Bug#951891: open-ath9k-htc-firmware: adoption status
Control: tags -1 help Control: owner -1 jsc...@posteo.net Hi, I've been quiet on this important package for a little while and ought to give an update, if nothing else to assure I've not bailed :). Recently I've been taking time to get acquainted with the tools, like gbp and friends, for a Git-only workflow seeing as upstream hasn't been making any formal releases. That need not be a blocker but I took up this opportunity. I'm now suitably comfortable to start fruitfully hacking and hope to have a candidate for a new upload in a week or two. Oleksij, thank you for your maintainership up-and-downstream, and thereby accommodating a dire need in free software. signature.asc Description: This is a digitally signed message part.
Bug#960875: e-antic ABI break
Control: reassign 960614 src:normaliz,src:e-antic Control: forcemerge -1 960614 See bug #960614, not only the test fails but normaliz is unusable as installed. signature.asc Description: This is a digitally signed message part.
Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio
On Sat, 25 Apr 2020 21:40:14 -0400 FeRD wrote: > If Debian maintains JUCE as a distro package, and it would be a compatible > alternative to our JUCE-based "libopenshot-audio", I don't see any reason we > can't add an option to libopenshot's CMake configuration that tells it to > just > use those libs, completely replacing libopenshot-audio ? which would > become entirely superfluous in that scenario. > > This is the perfect time to do it, too, as I've been gutting and reworking > large parts > of libopenshot's build system recently ? sticking in a "USE_SYSTEM_JUCE" > option would be no trouble at all. > > Is there an importable CMake configuration for the distro JUCE package, by > any chance, or should I put together a find module as well? That would be terrific. The version of JUCE that you updated is almost the same version as the Debian package, so I expect that would work well. There doesn't appear to be a CMake module. If you would create one or add an option to specify the path, that'd be the cleanest solution. signature.asc Description: This is a digitally signed message part.
Bug#960143: sagetex: FTBFS in unstable
On Mon, 11 May 2020 19:57:52 +0900 Norbert Preining wrote: > Uploading in the a few minutes, after the binary build succeeded. Just a ping in case you've moved on signature.asc Description: This is a digitally signed message part.
Bug#919769: Aw: Re: RE: firefox-esr: OB Firefox 60.4 crashes immediately on amrhf (Raspberry Pi)
On Tuesday, April 28, 2020 2:16:11 AM EDT hikaru.deb...@web.de wrote: > I'm sorry, but my Cubieboard is currently at my workplace, to which I have no access. I'll try to get clearance to pick it up, but I can't promise if or when that will be possible. It's not urgent, I wanted to ensure that you aren't having this issue anymore. Sorry if it was unclear, I'm not a Firefox maintainer and wouldn't have any clue how to fix this except for bringing it to Mozilla's attention. Take care. signature.asc Description: This is a digitally signed message part.
Bug#919769: RE: firefox-esr: OB Firefox 60.4 crashes immediately on amrhf (Raspberry Pi)
On Mon, 4 Feb 2019 19:00:59 +0100 hikaru.deb...@web.de wrote: > So I'd conclude this problem is specific to the Stretch/arm* architectures. Thanks. This bug looks like #909498. That was also reported on Stretch with a Raspberry Pi. Can you still reproduce it? Also look at #949834, but both individuals reported that from Bullseye or unstable. signature.asc Description: This is a digitally signed message part.
Bug#949834: [arm64] firefox-esr illegal instruction: reproduce in 68.5.0?
Control: forcemerge 948708 -1 Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1609535 Hi, This looks like #948708 which indicates this might've been fixed in 68.5.0. Could you upgrade if you haven't already and see if it crashes again? signature.asc Description: This is a digitally signed message part.
Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio
On Fri, 24 Apr 2020 23:33:59 -0400 FeRD wrote:
> Sorry, I realized I might have sent this reply to the wrong bug.
Yes, I sent my mail to both of the bugs (am doing now again, I guess). I am
also making noise :)
> What version of libopenshot is that result from? The Clang namespacing was
> fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in
> both libopenshot-0.2.4 and libopenshot-0.2.5.
I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm not
the maintainer; upgrading it is outside of my domain (esp. in light of the
following).
> That's a merge commit and it touches a bunch of files, but basically all of
> our headers now qualify juce symbols with the juce:: namespace prefix, and
> the test sources now #define DONT_SET_USING_JUCE_NAMESPACE
> which prevents JUCE from exporting its symbols into the global namespace.
>
> AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing
> over ambiguous 'UnitTest' symbols. But all this should have been solved
> months ago.
>
>> I'm uneasy about this and hope that a new release of OpenShot made with
>> the practices described in /usr/share/doc/juce-modules-source/README.Debian
>> will make an elegant solution.
>
> Is there a copy of that file online somewhere? It's not part of the JUCE
> distribution as far as I can tell, and it's definitely not located at that
> path on my Fedora machine.
Right, I know what'll pull it all together. It seems that the source for
libopenshot includes embedded code copies of JUCE, and code copies are
strongly discouraged in Debian, even if they don't make it into the binaries.
That file is a Debian-specific README mostly addressed to developers that says
to replace bundled copies of JUCE and use the code in package juce-modules-
source instead. This approach seems to have not been taken.
Coincidentally the embedded code copy discussion just came up on debian-devel,
and if no maintainer objects I'll add this to the 'big list' of embedded code
copies sometime soonish.
I hope this makes clear the nature of the obstacles ahead.JUCE for Debian
===
upstream's preferred form of usage of JUCE is to include a verbatim copy of all
used JUCE modules in your application.
This is made explicit in the 'Projucer', JUCE's own software project
management workbench, that will copy (or symlink, or include otherwise) the
modules' source code into your project.
# Projucer for Debian
Installing the following packages will give you the 'Projucer' as Debian
packages while keeping your embedded-module-code workflow:
- juce-tools (contains the Projucer)
- juce-modules-source (contains the source-code for the JUCE modules)
The 'Projucer' as shipped with Debian has the following modification regarding
the once shipped by upstream:
# Debian packages that depend on JUCE
This is a quick guideline for packaging upstream software that uses JUCE for
Debian.
For further implementation details check out the 'iem-plugin-suite' package.
- Build-Depend on 'juce-modules-source'
- Add 'Built-Using: juce-modules-source (= <>)' to debian/control
(replace '<>' with the actual version of 'juce-modules-source', as
obtained with
dpkg-query --show --showformat='${source:Version}' juce-modules-source
E.g. dh based packages might use something like the following in debian/rules:
JUCE_VERSION := $(shell dpkg-query --show --showformat='$${source:Version}' juce-modules-source)
override_dh_gencontrol:
dh_gencontrol -- -Vjuce:BuiltUsing="juce ( = $(JUCE_VERSION) )"
Accompanied by the following in the binary package's section in debian/control:
Built-Using: ${juce:BuiltUsing}
- If needed, dynamically link against the following libraries (as
"juce-modules-source" does not include their sources (as opposed to upstream):
- libjpeg
- libpng
- libflac
- libvorbis libvorbisenc libvorbisfile
- libogg
- zlib
E.g. using something like:
make LDFLAGS="$(pkg-config --libs libpng libjpeg flac vorbis vorbisfile vorbisenc ogg zlib)"
*Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
(>=5.4.4~repack0-3) which will take care of adding these libraries (if
required) to the LinuxMakefile build.
- When compiling for some embedded architectures (notably 'armel', 'mipsel' and
the like), you might need to link against '-latomic'.
The following snippet for d/rules can help inject the library on the required
architectures:
# link with libatomic on architectures without built-in atomic
noatomicarch = $(shell dpkg-architecture -qDEB_HOST_ARCH | egrep -x "(armel|powerpc|powerpcspe|m68k|mips|mipsel|sh4|riscv64)")
ifeq ($(if $(noatomicarch),atomic), atomic)
LDFLAGS += -latomic
endif
*Alternatively*, resave the JUCE-project with the Debian-packaged 'Projucer'
(>=5.4.4~repack0-3) which will take care of adding the relevant flags to the
LinuxMakefile build.
Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio
Control: block 925754 by 925755 Control: notforwarded 925754 Control: forwarded 925755 https://github.com/OpenShot/libopenshot-audio/issues/33 Hi, > On Wed, 29 Jan 2020 10:08:55 +0100 Matthias Klose wrote: > > libopenshot-audio 0.1.8 still fails to build > > Quite right, sorry. libopenshot-audio-0.1.8 fixed building with GCC *less > than* 9, > but GCC9 coming along broke it again. > > On Fedora / RPM Fusion we were building with commit 7001b68[1], > which was at the time an unreleased commit on the development branch. > > However, since then both 0.1.9 and 0.2.0 have been released, > including fixes to build with GCC 9 and 10 respectively, IIRC. > (I know 0.2.0 builds with GCC 10 for sure, since I've done it myself.) > > Current releases: > > libopenshot-audio-0.2.0: > https://github.com/OpenShot/libopenshot-audio/archive/v0.2.0.tar.gz > > libopenshot-0.2.5: > https://github.com/OpenShot/libopenshot/archive/v0.2.5.tar.gz > > OpenShot 2.5.1 (openshot-qt): > https://github.com/OpenShot/openshot-qt/archive/v2.5.1.tar.gz > > > [1]: > https://github.com/OpenShot/libopenshot-audio/commit/7001b68787c0881a44bcafba98cccae509a31644 libopenshot-audio builds with Clang without any modifications. Using this OpenShot (again with Clang) gets a bit farther: /usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17: note: candidate found by name lookup is 'juce::UnitTest' class JUCE_API UnitTest ^ /<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is ambiguous I've seen this is fixed in a commit upstream, and I think cherrypicking it helped, but the -audio Debian package uses the Juce embedded code copies instead of the ones in juce-modules-source as best as I can tell. I'm uneasy about this and hope that a new release of OpenShot made with the practices described in /usr/share/doc/juce-modules-source/README.Debian will make an elegant solution. signature.asc Description: This is a digitally signed message part.
Bug#955975: Massive memory leak in openshot 2.4.4 leads to freeze
Control: forwarded -1 https://github.com/OpenShot/openshot-qt/issues/2237 Control: forwarded 925754 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925754 Control: tags 925754 + fixed-upstream ftbfs Hi, > Version: 1:2.4.4-dmo4 OpenShot 2.4.4 isn't part of Debian yet. It seems you've probably gotten your package from a third-party repository. Have you tried the 2.4.3 package? If you're using Buster it should be available. OpenShot is broken on newer releases for the time being however. signature.asc Description: This is a digitally signed message part.
Bug#951891: open-ath9k-htc-firmware FTBFS with binutils 2.34
> thank you! > > I updated the package. Hi, I see you've fixed this upstream. firmware-ath9k-htc has been removed from Bullseye, could you use some help with a new Debian package? signature.asc Description: This is a digitally signed message part.
Bug#952060: libsignon-glib FTBFS: a few non-trivial ways to fix
This is caused by GLib => 2.58 which was uploaded in September 2018 long ago. Likewise, libsignon-glib 1.12 lags behind upstream substantially. It's 2.1 and the disparity causes the patch to not apply. A cheap workaround might be to add a -Wno-error like is already done for some other deprecated functions. (That has since been fixed upstream proper.) But in version 1.13, the NEWS file says * Build: don't emit a build error on deprecations so perhaps to fix this "cleanly" without such a leap, this avenue may be most suitable (perhaps 1.15). signature.asc Description: This is a digitally signed message part.
Bug#948940: Merge requests for FTBFS in Qt/KDE packages
I have now prepared merge requests for fixing ktp-common-internals, ktp-accounts-kcm, and kaccounts-providers respectively [1] [2] [3]. These issues are all fixed in new upstream releases, but I am not comfortable with such an undertaking and hope these fixes will suffice in the meantime. [1] https://salsa.debian.org/qt-kde-team/kde/ktp-common-internals/-/merge_requests/1 [2] https://salsa.debian.org/qt-kde-team/kde/kaccounts-providers/-/merge_requests/2 [3] https://salsa.debian.org/qt-kde-team/kde/ktp-accounts-kcm/-/merge_requests/1 signature.asc Description: This is a digitally signed message part.
Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)
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: >>> 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 > >> Is there a bug for libmath-gmp-perl for this test suite issue? > >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.
Bug#951398: pax.jar FTBFS: issue introduction
Hello, pax.jar seems to exist in version 2019.20191208-1 as well. If someone could affirm this is not an issue introduced with the new upload, could one set this bug as being found in 2019.20191208-1? This would enable the transition to testing. signature.asc Description: This is a digitally signed message part.
Bug#949236: ktp-common-internals FTBFS fixed upstream
Control: forwarded -1 https://phabricator.kde.org/D25269 Control: tags -1 fixed-upstream patch Control: reassign 949238 src:ktp-common-internals Control: reassign 949239 src:ktp-common-internals Control: forcemerge -1 949238 949239 Control: affects -1 + src:ktp-text-ui Control: affects -1 + src:ktp-contact-runner It seems that telepathy-qt 0.9.8 broke several packages and is the cause of #949236–949240. Fixing ktp-common-internals #949236 allows the latter two (ktp-text-ui and ktp-contact-runner) to build. I plan to prepare a merge request in the coming days. signature.asc Description: This is a digitally signed message part.
Bug#948940: kaccounts-providers FTBFS fixed upstream
Control: forwarded -1 https://cgit.kde.org/kaccounts-providers.git/commit/?id=fd6b3ebf Control: tags -1 patch fixed-upstream This was caused by the newer version of Qt and builds with the patch. signature.asc Description: This is a digitally signed message part.
Bug#949237: ktp-accounts-kcm FTBFS fixed upstream
Control: forwarded 949237 https://phabricator.kde.org/D25370 Control: tags 949237 patch fixed-upstream This was caused by the new telepathy-qt and the patch suffices for it to build on my system. #949239 in ktp-contacts-runner looks to be the same issue, but its git log is much less decipherable and doesn't show any change aside from version bumps. https://cgit.kde.org/ktp-contact-runner.git/ signature.asc Description: This is a digitally signed message part.
Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.
> Yes, it still crashes after opening any of images and trying to edit it or > just usin program GUI. If you had sent mail to the bug report before, it seems you're using a different email address now and I don't know if you have sent any debugging information before. Regardless, the following should be helpful. Can you run `reportbug -p --template pinta` and send back the system information that appears at the bottom of that? The output of `lscpu` might would also be helpful. How do you invoke Pinta? Do you use a command in a terminal to start it or click it from a menu? What does `mono -V` say? Do you use GNOME 3? Do you use any non-default graphics drivers, and does `mono /usr/lib/pinta/Pinta.exe --render-threads=1` fare any better? Are you usually working with a saved file when it crashes, and if you are, does opening a new window with an unsaved document make a difference? Sorry to bombard you with questions, but I hope these details shed light on the issue so you can figure out this puzzle. signature.asc Description: This is a digitally signed message part.
Bug#809997: emscripten not installable on Debian/testing...
Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5488 Control > The problem is that emscripten uses a fork of LLVM and I am reluctant to add > yet-a-new-version of llvm in the archive... > I have been waiting for the changes to be merged upstream and, with the > recent progress on webassembly, we are getting there... I haven't tried it, but it appears they enabled using Web Assembly with upstream LLVM in October. signature.asc Description: This is a digitally signed message part.
Bug#936481: Emscripten supports Python 3
Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/5950 Control: tags -1 fixed-upstream It appears it still supports Python 2 also for the time being https://github.com/emscripten-core/emscripten/issues/7198 signature.asc Description: This is a digitally signed message part.
Bug#851109: Emscripten violates font license
Control: forwarded -1 https://github.com/emscripten-core/emscripten/issues/10146 Control: block 939477 by -1 I've reported this upstream since they're still using it. signature.asc Description: This is a digitally signed message part.
Bug#946327: khotkeys FTBFS
Control: forwarded -1 https://salsa.debian.org/qt-kde-team/kde/khotkeys/merge_requests/2 Control: tags -1 patch This is fixed in KHotKeys 5.15.1. Alternatively, I've submitted a merge request to enable a potential new upload of 5.14.5 with the patch. signature.asc Description: This is a digitally signed message part.
Bug#946327: khotkeys FTBFS: fixed upstream
Control: tags -1 fixed-upstream The package builds with the following two commits applied in order: https://cgit.kde.org/khotkeys.git/diff/?id=67fd8f06 https://cgit.kde.org/khotkeys.git/diff/?id=ae574373 The former one makes many changes, but appears to be related only due to removing a blank line in a file, so that change could probably be consolidated. A naive uscan and uupdate got me to 5.17.4. With no additional changes this builds fine in sbuild, so maybe a new release would be more convenient. signature.asc Description: This is a digitally signed message part.
Bug#940839: Same bug with 2.4.4
Hello, > Same situation here with openshot 2.4.4 from debian sid. I have an intel gpu. OpenShot 2.4.4 isn't in Debian Sid yet. Where did you install it from? signature.asc Description: This is a digitally signed message part.
Bug#940839: openshot-qt crashes immidiately
Are you still able to reproduce this bug? In your logs I noticed the following > Debian Release: bullseye/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'), > (110, 'unstable')> > Architecture: amd64 (x86_64) It looks like you have a mixture of stable, bullseye, and unstable packages and that might provoke this. Do you know how this happened? signature.asc Description: This is a digitally signed message part.
Bug#897777: kvmtool: ftbfs with GCC 8
Control: tags -1 fixed-upstream I think this is fixed upstream. I found these commits that seem to be related: https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=05755b29 https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=96eda741 https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=eaeaf608 The last commit doesn't appear to be necessary to build with GCC 8, but it is the only additional error that was in Reproducible Builds's build with GCC 9. This might be sufficient to build with that too. signature.asc Description: This is a digitally signed message part.
Bug#936740: ipe-tools supports Python 3
Control: tags -1 fixed-upstream It looks like the current releases use Python 3 for svgtoipe now https://github.com/otfried/ipe-tools/commit/60ccc014 signature.asc Description: This is a digitally signed message part.
Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.
This bug has been open for a while and blocks Pinta getting into Debian Bullseye. Can you confirm whether or not you can still reproduce this issue? signature.asc Description: This is a digitally signed message part.
Bug#925758: librecad: ftbfs with GCC-9
Control: forwarded -1 https://github.com/LibreCAD/LibreCAD/pull/ Control: tags -1 upstream fixed-upstream ftbfs This has been fixed upstream. The change is at https://github.com/shawncurry/LibreCAD/commit/3bc93383 signature.asc Description: This is a digitally signed message part.
Bug#944616: emacs: FTBFS on mips64el, mipsel
Has anyone been working on this? signature.asc Description: This is a digitally signed message part.
Bug#940463: fixed in falkon 3.1.0+dfsg1-4
Control: reopen -1 Control: tags -1 unreproducible moreinfo Control: severity -1 normal If 3.1.0+dfsg1-4 doesn't have any changes from 3.1.0+dfsg1-3, why was it uploaded? That uses additional mirror space and rebuilds all of the packages. It also marks the bug as fixed in 3.1.0+dfsg1-4. Instead, if a bug isn't being fixed by a new upload, send the reason you're closing it to 940463-done@b.d.o with a Version: header reflecting if a version does have a fix. > As my last e-mail tells, I "Checked that falkon-3.1.0+dfsg1-3 does not > crash", which can be considered as being unable to reproduce the bug. Bugs shouldn't be closed solely for being unreproducible. Instead, add the tags and contact the submitter. I see you might've been desperate to get Falkon back into testing since the upload was the same day it was removed. Bugs serious, grave, and critical cause removal, so I've downgraded the bug to normal. > I got no reply from Xeno Idaltu , so I believe > that either he is not using falkon again, or he installed falkon's new > package and found the bug fixed. Did you reply to him separately from the bug report? The log doesn't show anyone reaching out to him. Additionally, I'm curious about this changelog entry > falkon (3.1.0+dfsg1-5) unstable; urgency=medium > * removed the dependency on libgnome-keyring-dev, since this package > is no longer part of Debian. Together with the upstream version > change, this ... Closes: #943769 since #943769 doesn't appear to be related to GNOME Keyring. I am also seeking to know why 3.1.0+dfsg1-3 has a +dfsg1-3 since the prior uploads were 3.0 and didn't have the +dfsg1. I haven't been able to find the reason for the change documented. I haven't been able to reproduce the bug. However, I hope my suggestions are helpful for you and that I'll be able to help Falcon in this way. Sincerely, John Scott signature.asc Description: This is a digitally signed message part.
Bug#933865: adb crashes on startup with SIGBUS
Control: reassign -1 android-libboringssl/8.1.0+r23-1 Control: tags -1 upstream patch fixed-upstream Control: retitle -1 adb crashes on startup with SIGBUS (armhf) Control: forwarded -1 https://boringssl.googlesource.com/boringssl/+/672f6fc2486745d0cabc3aaeb4e0a3cd13b37b12%5E%21/ Control: affects -1 adb Control: severity -1 serious (justification: it works on other architectures) > A package android-libboringssl build with that patch applied could > successfuly create the keys and did no crash on "adb devices" (just tested > without a device connected). signature.asc Description: This is a digitally signed message part.
Bug#940463: fixed in falkon 3.1.0+dfsg1-4
On Wed, 16 Oct 2019 10:00:15 + Georges Khaznadar wrote: > Source: falkon > Source-Version: 3.1.0+dfsg1-4 > > We believe that the bug you reported is fixed in the latest version of > falkon, 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. > > Changes: > falkon (3.1.0+dfsg1-4) unstable; urgency=medium > . >* Checked that falkon-3.1.0+dfsg1-3 does not crash. > Closes: #940463 Did a change to Falkon fix the issue, or is 3.1.0+dfsg-1-4 the same as 3.1.0+dfsg-1-3? Was the submitter's issue resolved or were you unable to reproduce the crash? signature.asc Description: This is a digitally signed message part.
Bug#925826: shim: FTBFS w/ GCC 9 fix
Control: tags -1 patch Merge request with fix at https://github.com/rhboot/shim/pull/170
Bug#922574: digiKam FTBFS with OpenCV 4
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306 This appears to have been fixed upstream. There are a couple patches there.
Bug#907231: Ping - ktp-contact-list FTBFS
ktp-contact-list has been kept out of testing for over a year, though this issue is fixed by the patch and new upstream version. If help is wanted with this, please let it be known.
Bug#936270: Please fix calibre, or get it out of Debian
On Mon, 14 Oct 2019 16:05:04 +0200 Thomas Goirand wrote: > it wont change the fact that Python2 is being removed from Bullseye because it's dead upstream on the 1st of January next year. That's not a fact, Bullseye can still ship with Python 2 if needed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931659#17 signature.asc Description: This is a digitally signed message part.
Bug#934171: sagemath: FTFBS with libreadline8
Control: block -1 by 933021 The FTBFS / 22,979 test failures are due to #933021, and until it's fixed I don't think it can be determined whether libreadline8 might cause them too. signature.asc Description: This is a digitally signed message part.
Bug#917884: (no subject)
Control: severity -1 important Control: found -1 0.75-1 Could you be using Wayland by any chance, like with GNOME 3? For me, mate-panel crashes there regardless of applets used. Since the applet works fine for me, I hope you don't mind that I reduce the bug severity. I suggest that you try invoking mate-panel from the command-line, attempt to add the applet again, and see if it gives any output that might be meaningful to be posted here. signature.asc Description: This is a digitally signed message part.
Bug#894313: etherape: Crashes on startup
Package: etherape Version: 0.9.16-1 Followup-For: Bug #894313 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I am able to reproduce this issue, but installing libgnomeui-0 (which provides libgnome.so) fixes it for me. Like the upstream report suggests, this looks like a missing dependency. - -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages etherape depends on: ii etherape-data0.9.16-1 ii libart-2.0-2 2.3.21-3 ii libatk1.0-0 2.28.1-1 ii libc-ares2 1.14.0-1 ii libc62.27-2 ii libcairo21.15.10-1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglade2-0 1:2.6.4-2+b1 ii libglib2.0-0 2.56.0-4 ii libgnomecanvas2-02.30.3-3 ii libgtk2.0-0 2.24.32-1 ii libpango-1.0-0 1.42.0-1 ii libpangocairo-1.0-0 1.42.0-1 ii libpangoft2-1.0-01.42.0-1 ii libpcap0.8 1.8.1-6 ii libpopt0 1.16-10+b2 ii libxml2 2.9.4+dfsg1-6.1 etherape recommends no packages. etherape suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlrAD0ASHGpzY290dEBw b3N0ZW8ubmV0AAoJEH1hRKYneTBy0L0H/0M8r1h/xu7VYeNDoAgbRlZpVFHTIAbL /oPwqt048gnKAn4Mngfd66gIfCJ437IK4g0RLHCLp3Ysn3kF9cA5uHPhPVVOnW4A eHbDuvxUB4AVP0xRTbm1xspWiukxS6Wiukr+YeyiLq9OA3ZAcKaAUedv5K7SsuzL DcYjSVZ4TmZxcToTpxxv5UktPot1qARSyeTP7/pwIEHO8lZxn8hQYuzmYGsZyyJW CH1j1Q/+nBPMXwtmX7TDG49HtSXoyaNgxDY8baTIFsgEJmLm34nWqDbmExHjqzL+ tRDsQqShmLmwzArPSBQJ23yGvIWNdVfzVfG0OuRq04qxt2mt3bvBzZI= =M1mF -END PGP SIGNATURE-
Bug#888957: linuxbrew-wrapper: Linuxbrew formulas may build or install non-free software
Package: linuxbrew-wrapper Version: 20170516-2 Severity: serious Justification: Policy 2.2.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Though the linuxbrew-wrapper package is free just as Linuxbrew is, Linuxbrew does not commit to only free software. Linuxbrew's OpenCV formula builds with -DOPENCV_ENABLE_NONFREE=ON, and FFmpeg builds with --enable-nonfree. Though a comment in ffmpeg.rb notes that the flag produces unredistributable binaries, no notice is given to the user. Users that commit to only using free software may install this package and believe that it is free because it is in main. Though the package is free, and Linuxbrew is free, the purpose of Linuxbrew and this wrapper package is to install software from outside of the Debian repository (some of which is non-free). I believe that this violates Debian Policy that packages in main "must not require or recommend a package outside of main for compilation or execution." Because this package is a wrapper that will "invoke upstream install script if found no linuxbrew instance" upon installation, I believe package is not suited for main and is probably better suited for contrib. The Debian Policy Manual says that packages that would be included in contrib include "wrapper packages or other sorts of free accessories for non-free programs." Linuxbrew is a wrapper for installing (with or without building from source) programs that, though many of them are free, some are not. - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linuxbrew-wrapper depends on: ii build-essential12.4 ii curl 7.58.0-2 ii git1:2.15.1-3 ii python-setuptools 38.2.4-2 ii ruby 1:2.3.3 linuxbrew-wrapper recommends no packages. linuxbrew-wrapper suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQFGBAEBCgAwFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlpx4wESHGpzY290dEBw b3N0ZW8ubmV0AAoJEH1hRKYneTBy+e0H/iaJPxn/cQZVjjthqo674US+CXSTfw/+ shS/OmKzvUKfkFF0g0sKyhHmZTPTJtu6fAjYtSjMVLBwJud/nwhv5j5RJ/C/vZKl zV7JdkL/swOCP/vU5zDWcHpemhyi+JRpujeAIfeghBrASSSj3O1Y8a9N+gsqovCK HE0/qj63Yg1Qk3o5jlcBmf3MrVAjSCTUYofvpnShYwhqpUGAW1VTCAh/CRrvbOpZ ssjJsDrTJCqExPLTOINx9tTNk+CCNXQv1xGmmzi9TDB+SUJgkc9IeF4m/IEKzkqE AkQFIes3WCFOm81cgKd5tWHpbUtXL6YCf/X1tzmJqUWYCGChtXaS7Rs= =QV9z -END PGP SIGNATURE-
Bug#802017: xmoto: Text does not appear in-game
Package: xmoto Version: 0.5.11+dfsg-2 Severity: grave Justification: renders package unusable Dear Maintainer, I've noticed that in package version 0.5.11+dfsg-3, text, both during gameplay and in the menus, does nor show and makes the game completely unplayable. Downgrading to 0.5.11+dfsg-2 solves this issue. I'm using Intel Ivybridge integrated graphics on Debian Unstable. This issue is present as soon as the game is opened. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xmoto depends on: ii libbz2-1.01.0.6-8 ii libc6 2.19-22 ii libcurl3-gnutls 7.45.0-1 ii libgcc1 1:5.2.1-22 ii libgl1-mesa-glx [libgl1] 10.6.8-1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libjpeg62-turbo 1:1.4.1-2 ii liblua5.1-0 5.1.5-8 ii libode1 2:0.11.1-4.1 ii libpng12-01.2.50-2+b2 ii libsdl-mixer1.2 1.2.12-11+b1 ii libsdl-net1.2 1.2.8-4 ii libsdl-ttf2.0-0 2.0.11-3 ii libsdl1.2debian 1.2.15-11 ii libsqlite3-0 3.8.11.1-1 ii libstdc++65.2.1-22 ii libxdg-basedir1 1.2.0-1 ii libxml2 2.9.2+zdfsg1-4 ii xmoto-data0.5.11+dfsg-2 ii zlib1g1:1.2.8.dfsg-2+b1 xmoto recommends no packages. xmoto suggests no packages. -- no debconf information
