Bug#964423: FTBFS: QDesktopWidget::screenGeometry is deprecated
On 7/7/20 2:21 AM, John Scott wrote: > Rebuilding dspdfviewer to see how it would fare with Poppler in > experimental, I found it FTBFS in unstable unconditionally. > > /<>/pdfviewerwindow.cpp: In member function > ‘void PDFViewerWindow::reposition()’: > /<>/pdfviewerwindow.cpp:119:89: error: ‘const QRect > QDesktopWidget::screenGeometry(int) const’ is deprecated: Use > QGuiApplication::screens() [-Werror=deprecated-declarations] > Hello John, thank you for bringing this to my attention. I will make a patch and report back on this bug. Regards, Danny
Bug#777833: digikam: ftbfs with GCC-5 (patch)
tags 777833 patch thanks Hello all, I tried to rebuild digikam on sid today. The current version still misses libsoprano-dev dependency and fails with: > make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 'lib/libkvkontakte.so.1.0.0'. Stop. Once a build-time dependency on libsoprano-dev was declared, I was able to compile digikam on a sid sbuild, it linked against the new opencv-*2.4v5 libraries. - Danny diff -Nru digikam-4.4.0/debian/control digikam-4.4.0/debian/control --- digikam-4.4.0/debian/control2014-11-15 17:37:35.0 +0100 +++ digikam-4.4.0/debian/control2015-08-10 14:51:04.0 +0200 @@ -6,6 +6,7 @@ Build-Depends: debhelper (>= 9), pkg-kde-tools (>= 0.9), pkg-config, cmake (>= 2.6.2), doxygen, kdelibs5-dev, kdepimlibs5-dev, + libsoprano-dev, libmarble-dev, libkipi-dev (>= 4:4.12), libkexiv2-dev (>= 4:4.12), libkdcraw-dev (>= 4:4.12), libksane-dev, baloo-dev, libkfilemetadata-dev,
Bug#797917: Actually this bug makes clang not so useful
On Thu, 3 Sep 2015 17:45:27 + (UTC) Gianfranco Costamagna wrote: > according to [1] there might be no fix. > This may not be a permanent fix, but Debian could take up the "dual-abi" idea that gcc upstream does with their libstdc++.so.6. Example: $ nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt | grep std::locale::name 0009e300 T std::locale::name[abi:cxx11]() const 000b8900 T std::locale::name() const For reference, the un-beautified symbol names are 0009e300 T _ZNKSt6locale4nameB5cxx11Ev 000b8900 T _ZNKSt6locale4nameEv The symbol is exported twice, once with the new ABI and once with the old. If someone™ figured out how to make the gcc compiler do that, boost (and other libraries') maintainers could adapt those flags when compiling with gcc, so we don't generate a vendor lock-in. If we could make those "Dual-ABI compile flags" the default on gcc-compiled libraries, clang upstream should have enough time implementing [abi:cxx11] and remain usable in Debian. - Danny
Bug#797917: Actually this bug makes clang not so useful
On 04/09/15 11:23, Gianfranco Costamagna wrote: > > I guess clang is not useful for cxx11 projects until llvm folks finds > a way to make it use the new ABI. > Hi everyone, I just want to make clear that this is *not* specific to c++11 projects. Even if you don't use any c++11 features, clang can't link against the library. Try compiling my example code (which is valid c++98) with $ g++ -std=c++98 -o options options.cpp -lboost_program_options $ clang++ -std=c++98 -o options options.cpp -lboost_program_options The results are the same - works on gcc, fails to link on clang on sid, while both commands used to work on stable. If I understand the consequences of this failure right, this will severely impact the usefulness of clang++, since it will start failing to link against *any* c++ library compiled by recent g++, breaking unchanged and valid user code - be it c++11, c++03 or c++98. I don't think this is that much of an issue on sid - after all, it's called "unstable" for a reason - but it might be a showstopper for stable, if clang++ is to be an alternative for g++. - Danny
Bug#777833: digikam: ftbfs with GCC-5
On Sat, 08 Aug 2015 00:56:48 +0200 Christoph Anton Mitterer wrote: > Hey. > > Anything new here? That blocks upgrading to to current libstdc++6 > (without removing a large number of packages) and thus also prevents > other packages (that already depend on newer libstdc++6) with important > security updates to be installed. > > Cheers, > Chris Hello Chris, I've tried to reproduce the build failure, and I got a little different results than above, so I'm sharing them in the hope they benefit in tracking down the bug. Unmodified package I tried apt-get source digikam, followed by sbuild --dist unstable digikam_4.4.0-1.1.dsc It ran for a while, and then failed with the following message: make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by 'lib/libkvkontakte.so.1.0.0'. Stop. Full log (>400kb) can be downloaded from http://danny-edel.de/logs/digikam_4.4.0-1.1_amd64-20150810-1415.build With libsoprano-dev in Build-Depends: For testing purposes, I added "libsoprano-dev" (which contains this file) to build-depends and created a new source package (Please ignore the incremented version number), and got a different failure: CMakeFiles/kface.dir/detection/opencvfacedetector.cpp.o: In function `KFaceIface::Cascade::Cascade(QStringList const&, QString const&)': /«PKGBUILDDIR»/extra/libkface/libkface/detection/opencvfacedetector.cpp:130: undefined reference to `cv::CascadeClassifier::load(std::__cxx11 ::basic_string, std::allocator > const&) Full log (>500kb) can be downloaded from http://danny-edel.de/logs/digikam_4.4.0-1.2_amd64-20150810-1455.build I hope this helps in getting Digikam to run again. To me, the second failure looks like cv needs a rebuild to expose the new __cxx11 symbols, before digikam can compile cleanly with GCC5. However, I don't know how to request that, or check whether it has already been requested. - Danny -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#797917: Porting the patch to debian?
Hi, I would like to try one of the patches from upstream, but I can't figure out how to apply them to the sourcecode I grab with "apt-get source clang-". In particular, neither the patch from https://llvm.org/bugs/attachment.cgi?id=14874 nor the newer one from http://reviews.llvm.org/D18035?download=true applies (quilt import -> quilt push dies with "can't find file to patch"). Could someone help me by porting that patch against the Debian version of clang, or even by uploading a patched version to experimental? I would gladly test and provide feedback, right now clang is near-unusable since pretty much every c++ library in Debian uses those abi tags. Thank you in advance, Danny
Bug#777791: [PATCH] ball: ftbfs with GCC-5
On 05/04/2016 02:19 PM, Andreas Tille wrote: > Any success with you alioth commits? Did you possibly pinged alioth > admins via IRC? I'd love to get you properly working as any normal > Debian Med member. If not I'd try to investigate. Hello Andreas, sorry for the late reply, but I have been able to commit now. Thank you for fixing this. I mirrored my changes as "fix-debian-bug-91" branch to debian-med/ball.git, and deleted the temporary mirror. The work I pushed is equal to the patch from the last email, so it can be ignored now. I then rebuilt the package on a fresh sid cowbuilder, but now there's a new problem (see attachment for the exact error message) near the end of the build, involving a static_cast. I will look into that of course, but I did not want to overwrite the "master" branch before contacting you, especially not with a not-anymore-working solution. Will report back here, - Danny [ 79%] Building CXX object source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/VIEWmodule/sipVIEWpart2.o /build/ball-1.4.3~beta1/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart2.cpp: In function 'void* cast_Box(void*, const sipTypeDef*)': /build/ball-1.4.3~beta1/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart2.cpp:3184:45: error: invalid static_cast from type 'BALL::VIEW::Box*' to type 'BALL::VIEW::Vertex2*' return static_cast(sipCpp); ^ source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/build.make:383: recipe for target 'source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/VIEWmodule/sipVIEWpart2.o' failed
Bug#777791: [PATCH] ball: ftbfs with GCC-5
On 05/10/2016 07:13 PM, Andreas Tille wrote: > Thanks a lot. Your work is really appreciated. Please also be bold and > commit to master. I have no time to look the next 2-3 days - but I'd > like to see the changes in master since I see no point in deriving for > this package what we are doing anywhere else. Hi Andreas, I have backported a fix for the Python issue and ball now builds in a fresh sid cowbuilder. I also un-deleted the 0001-missingSigned.patch, since I realized it is needed on ARM, where "char" is "unsigned char" by default, causing FTBFS when assigning -1 to a "const char". This may be a candidate for a pullrequest to the newly moved upstream github repository. All patches are uploaded to "master", the work-in-progress branch is deleted. To me the resulting package (now without any weird hacks and old packages from snapshot.d.o) seems usable: I started BALLView and loaded random projects from /usr/share/BALL-1.4/data/projects, and I get molecule renderings on my screen -- but I have no idea if these are the right ones : ) Cheers, - Danny signature.asc Description: OpenPGP digital signature
Bug#777791: [PATCH] ball: ftbfs with GCC-5
On 05/18/2016 08:45 AM, Andreas Tille wrote: > Could you please add your changes to debian/changelog? If you use > > dch > > it injects a separate section for your ID. Hi Andreas, I updated the changelog with dch and it tagged the changes with my name. The commit is in master. I hope its all right. - Danny
Bug#830984: Do you have resources to look after ball? [progress info]
Control: block 784451 by 832420 On 11/10/2016 09:13 PM, Andreas Tille wrote: > I take the freedom to turn this discussion into a public one > and CC the relevant bugs to leave a record there that something is > happening. Hello Andreas, that is fine with me. I'll keep the bugs in CC too. > Hmmm, may be we should base the packaging on a later upstream commit? > >> Among >> other things, upstream also migrated from Qt4 to Qt5, and incorporated a >> few fixes for recent boost. > > We somehow should target to Qt5 anyway (see #784451) better sooner than > later. > For now, I have backported the fixes to the released, but Qt4-based 1.4.3~beta1 version, to resolve the current FTBFS with a targeted fix. The changes are uploaded to the debian-med/ball repository on alioth, pending your review and upload. In that process, I tried building various stages of upstream master, and bae96ab4 'Merge branch issue_596' might be a candidate for a snapshot (entire testsuite passes). However, there is the problem that QtWebEngine is not yet included in Debian, so I could only build recent master if I explicitly disabled support with -DUSE_QTWEBENGINE=OFF. I am not sure if this would be a good thing for users. I added a blocking relationship to the ITP of QtWebEngine, I hope I didn't mix up the numbers. The changelog contains a Closes: clause on both FTBFS issues, even though I could only test amd64. Feel free to remove those before uploading if that's an issue. Cheers, Danny
Bug#830984: Bug#833004: Do you have resources to look after ball? [progress info]
On 11/11/2016 02:29 PM, Andreas Tille wrote: > Start 197: AmberFF_test > 197/334 Test #197: AmberFF_test .***Failed > 0.19 sec > (...) > (line 511 TEST_REAL_EQUAL(r4_r1 - r4_i, r1_r4 - r1_i): got -145.471, > expected -103.957) - > (line 513 TEST_REAL_EQUAL(r1_r4 - r1_i + r1_tpl + r4_tpl + tpl_i, > total_energy): got 1680.36, expected 1638.84) - > FAILED > FAILED > Considering Steffen's answer it might be worth trying the said > snapshot if this might be fixed there. Hello Andreas, hello Steffen, this looks like upstream bug [584][], and appears to be intermittent, but from what I can tell, no code has been added to address this in upstream master. So upgrading to a snapshot would not necessarily help. However, I can *not* reproduce the AmberFF_test failure. Neither in my Debian testing environment, nor in an unstable chroot freshly created with git-pbuilder. I literally ran the AmberFF_test one thousand times and it did not fail once. Of course, that doesn't mean it won't fail on the 1001st time, but I have no idea how to effectively approach this without deep knowledge of the program and its algorithms. Since we're talking floating-point arithmetic, and the results are not completely off (same sign, and at least within the same order of magnitude), this may be a hardware-specific corner-case resulting in greatly reduced precision. For reference, I'm running on an Intel Core2 6600. Trying the same code again and expecting a different result might not be very professional (or even sane), but we could upload to a buildd (experimental?) and see if the failure is reproducible there. Of course, it is always an option to exclude this test to restore buildability. The quality would certainly not be worse than before, when the testsuite was skipped entirely. [584]: https://github.com/BALL-Project/ball/issues/584 Bottom line: As much as I'd like to help out; without access to a box where the problem is reproducible, I am not able to. Best regards, Danny signature.asc Description: OpenPGP digital signature
Bug#830984: fixed in ball 1.4.3~beta1-2 -- only on amd64
Control: reopen -1 On Sun, 13 Nov 2016 09:18:53 + Danny Edel wrote: > We believe that the bug you reported is fixed in the latest version of > ball, which is due to be installed in the Debian FTP archive. Hello Andreas, hello Steffen, it seems like the fixes were indeed only effective on amd64, so I am reopening the FTBFS/test-suite bug. Also, I removed the other bugs from CC, so you don't get each mail 4 times : ) From what I can tell, the testsuite failures fall into two categories: 1. Most likely completely harmless, -- 0.01 difference in a floating-point calculation. The PoseClustering_test seems to be involved in this on a few arches, where it compares a string rendering (letter-by-letter) instead of using a fuzzy-compare of the values. * arm64 * ppc64el 2. Something is really broken and needs debugging on the appropriate hardware. Segfaults, integer mismatches (8 != 0), really weird output, etc... * i386 * s390x * kfreebsd-amd64 * kfreebsd-i386 * powerpc * x32 [at the time of writing, not all arches had finished/failed] In the case of kfreebsd, the source will likely need patches for the different kernel, since Sysinfo_test fails with statements like: TEST_EQUAL(getTotalMemory() > 0, true): got 0, expected 1) I fear that the tests are likely to keep failing on non-amd64 architectures until someone with access to a corresponding box puts in the effort to investigate, and adjust the tests for the subtle differences. Until then, I propose to run, but ignore the return code, of the testsuite on "anything other than linux-amd64" for now, to have a chance of re-entry into stretch. Rationale behind running anyway: We can load the logfile and grep for '*Failed' to keep track of the problematic tests. This string also works great with the web interface and the ctrl+f feature of most browsers. Rationale behind ignoring right now: I assume that the vast majority of users run amd64 (popcon backs me on this), and those would benefit from seeing the package in stretch. Even on the now-FTBFS arches, the (comprehensive) testsuite suggests that 99% of the library is working as intended, which should qualify the problem as important, but not release-critical in my opinion. If (!) there is a userbase of BALL on Debian-but-non-amd64/non-linux, there is also the hope one of them will step up and provide assistance in tracking this down or confirming the actual impact, which is a lot easier if the package is available as a binary. What is your opinion? Danny -- PS: I submitted a basic travis-ci configuration to upstream for review. If it gets accepted, I can work from there to approach the 'will-it-build-on-jessie/stretch/sid/xenial' question. signature.asc Description: OpenPGP digital signature
Bug#830984: fixed in ball 1.4.3~beta1-2 -- only on amd64
On 11/13/2016 05:55 PM, Andreas Tille wrote: > Hi Danny, > > I fully agree that we should ignore test results on other than amd64 > architecture. Please let me know if you intend to implement the needed > change or whether you suggest that I should do so. > > Kind regards > > Andreas. > Hello Andreas, I have created and git-pushed a patch to debian/rules. I did not update the changelog, since it didn't look like the one uploaded to unstable earlier today and I wanted to avoid a merge conflict on your side. If you could review / edit changelog / upload, that would be nice. A quick test on an i386 chroot with the build command replaced by /bin/true suggests it does exactly what it's supposed to. It ran the test suite, ignored the inevitable error and issued a diagnostic. It even printed my warning multiple times : ) The computer will ignore it of course, but it might prompt a human reader to get involved. If the new revision actually builds, I would suggest we keep this bug open (I wrote the bug number into d/rules) and downgrade its severity to important. I don't have the time right now to dig into the i386 issues in detail. If that changes, I might un-dust my old Celeron-based laptop and let it compile for a few days. If it can actually run stretch/sid. I remember reading something on d-devel about raising the minimum processor requirements for the i386 port… Cheers, Danny signature.asc Description: OpenPGP digital signature
Bug#845106: x11vnc: configure does not find libssl, builds without OpenSSL support
On Sun, 20 Nov 2016 13:37:46 +0100 Hilko Bengen wrote: > after searching for "AC_CHECK_LIB(ssl, SSL_library_init" using > codesearch.debian.net and rebuilding with OpenSSL 1.1, I found that the > OpenSSL is no longer detected and thus no longer used when building the > package. Hello, is anyone already working on this? If not, I would try resolving this myself, since I use x11vnc a lot and would very much like to see it in stretch. The autoremoval because of this bug is currently scheduled for January 3. Cheers, Danny
Bug#797038: add patch
On Sat, 9 Jul 2016 23:51:52 +0200 Matthias Klose wrote: > patch at > http://launchpadlibrarian.net/271939349/llvm-toolchain-3.8_1%3A3.8.1-2ubuntu1_1%3A3.8.1-2ubuntu2.diff.gz Hello Matthias, thank you very much! This patch solves the issue for me, clang++ now compiles *and* links against abi-tagged c++11 libraries, and I have not encountered any problems yet. Cheers, Danny
Bug#809136: Don't migrate borgbackup to Debian stable
Control: retitle -1 Block borgbackup migration to stable for now Hello everyone, I have thought a lot about this situation and I still think that blocking migration to stable *for now* is the sensible solution. I do not want to remove borgbackup from Debian, or keep this blocker alive indefinitely, just to clarify that. The "opener" of this ticket was the situation that you cannot connect to a borgbackup-0.28.0 server with a borgbackup-0.29.0 client or the other way around. This alone - as David pointed out - should not normally qualify for a blocker. Solving this issue in the way upstream suggests (having a borg-0.28 and a borg-0.29 command) would require changing installation paths so that both versions could coexist, and adding versioned binary names. While some work, that is not impossible, however it would still need "backports" of the old client versions to the current Debian sid, which may get a bit complicated and difficult to maintain. Now please keep in mind that borgbackup is *a backup software*. Users generally trust backup software with their most important data (we keep saying "make backups" for a reason) and even though the QA department says they should, most users don't test continually whether they can actually restore the backup with each new version of the backup software. I do not know if this is general consensus, but personally I would expect from any backup software included in Debian stable, that I can restore my data using the newer version in the next Debian stable. If a backup software does not qualify for that criteria, I would expect to be actively warned (versus requiring me to read the changelog) before I install/use it. Borgbackup currently does not meet that standard. In fact, they state "Expect that we will break compatibility repeatedly (...) like when going from 0.x.y to 1.0.0" on their front page in all-caps. You can read some discussion about backwards-compatibility in upstream issue #1 on github. I think it's safe to assume that once borgbackup reaches milestone 1.0.0, they will care a lot about (at least read-only) on-disk backwards compatibility, and maybe even RPC compatibility between 1.x and 1.y client/server. So this would be the time when I personally think it's ready for Debian stable. While it could be argued that with the same reasoning it should not be in Debian at all, I think having the package in unstable is actually beneficial both to Debian users and upstream development. I assume that a Debian *unstable* user is aware of the fact that this is relatively new software, and that a large portion of "unstable" userbase are developers and early adopters, that are willing to try new things out and submit helpful bugreports and feature requests. This kind of feedback can be very beneficial to upstream, and since those users will regularly update to the newest version, the backward-compatibility issue is not as present here. In essence, my main issue here is keeping up the high quality that users expect from a Debian stable. So unless we find some way to ensure users have read (and acknowledged) a statement about (non-)compatiblity before they install it, I don't think it should migrate into Debian stable until upstream starts to make that promise. This has been a rather long message, but I hope it clarifies the reasoning why I belive this is a blocker for stable migration. As always, discussion is appreciated and maybe someone has an idea or a solution I have not yet thought of. Thank you in advance, - Danny PS: Please don't CC me in replies, being co-maintainer I am subscribed to the bug.
Bug#809136: Block borgbackup migration to stable for now
Hello Antoine, thank you for your detailed answer. I will try to address inline. On 01/08/2016 10:45 PM, Antoine Beaupré wrote: > Borg has actually shown great API stability since it forked from > Attic. The change that occured was necessary, and was well documented > in the release notes and the manual. (It should have been documented > in the NEWS.Debian file in the Debian package as well.) It is also the > *only* one that happened in over 15 releases since the fork from > Attic. We can even still convert older, prehistoric attic repositories > to borg without data loss. My statement that borgbackup does not make any compatibility guarantees was a quote taken from the top-level README.rst (near the bottom of the file), not by inspecting the actual source code history. If it is no longer accurate, you might want to update that paragraph in the upstream README, since this statement reads very different. I apologize if I made the wrong conclusions, and I think we can find a good solution to this. > Furthermore, this only concerns the backup remote RPC protocol. The > storage format is *still* compatible, all the way back to attic. If > you have a copy of your repository, you can still backup to and from > it. If your server is upgraded, it is true that you do need to upgrade > your client, however (and vice-versa). Thank you for the clarification, I will include this in README.Debian and (in future releases, if there is another incompatiblity) in a NEWS.Debian. > But tons of backup software in Debian have that behavior: unison was > already mentionned, but rdiff-backup also has the same problems. That > is why we have backports: when the server side upgrades, we upgrade > the clients to the backports version. It's annoying, but it works, and > rdiff-backup has been in Debian for a long time. Those other backup > softwares are way more popular, sometimes by orders of magnitude, than > borg: I understand this solves the issue about writing to a new (testing/unstable) server with an old (stable) client. I know this is irrelevant if borg-1.0 gets released before stretch (which I hope it does), but can you clarify how borg does/will handle "old server, new client"? > Keeping borg from entering stable (or, more precisely, testing in this > case) is exactly what we *don't* want here. If we keep borg from > entering testing, we keep it from being backported. If we keep it from > being backported, we make it *harder* for people to run the same > version of borg across different versions of Debian. So we basically > make the Debian package useless, which means people won't use it and > will instead use the pip version. > > Is that what we want? Very good point. No I don't want to end up there. On a Debian system, the installed software should be managed by apt/dpkg. > I was looking at backporting borg from stretch to jessie, but if the > maintainers are going to remove it from stretch, i'm certainly not > going to bother, and that would be a shame... A backport would be really nice to have, so please don't give up on this yet. In essence, all I want is a solution on how to ensure that users don't get surprised. > Finally, keep in mind that this is a problem only in Debian, and only > if we have multiple, incompatible versions of borg in > Debian. (Non-debian installs can use virtualenvs to install as many > borg versions as they want.) Right now, we only have one version > (0.29.0-2), and it's compatible between unstable and testing. If > testing gets released right now, stable, testing and unstable are all > compatible, and we have absolutely no problem. Agreed. Currently there would not be a problem, but it will be one when upstream releases another API-breaking release. The main point of this ticket is to figure out how to be prepared for that next time it happens. > Furthermore, it's very likely that borg 1.0 gets released before > stretch, so all those arguments will be completely irrelevant because > borg *will* be API stable. Yes that would be perfect. > > This, in short, is a non-isse right now. If 0.28 was in stable and > 0.29 in testing, this would be a bug, but then the fix would be a > backport, not a removal from stable (which you can do, if you are > really stuck, anyways). > > Now, can i open this bug about backporting? :) > > a. Let's resolve this situation first and close this bug (so the testing-autoremoval is disabled), then create the backport. Let me try to summarize to check if I understood you correctly: 1. The incompatibility warning from README only affects the network communication between different versions, not the on-disk format 2. Borgbackup already makes the "read back your old backups with a new software version" promise, all the way back to attic repositories. 3. By using your backport, #1 will be solvable by the enduser directly without having to resort to non-apt-managed software installation. #1 would in my opinion downgrade this ticket from serious
Bug#777791: ball: ftbfs with GCC-5
Hello Andreas, hello list(s),
I tried to reproduce this build failure on a current sid and investigate
a bit. On my machine it outputs the same basic error messages (although
the line numbers in the basic_string template file are a bit different).
I try to quote the error message partially so it becomes a bit clearer
what is really going on:
On 01/07/2016 01:12 PM, Andreas Tille wrote:
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC: In member function
> 'BALL::String& BALL::String::insert(BALL::String::const_iterator,
> std::initializer_list)':
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: error: no
> matching function for call to
> 'std::__cxx11::basic_string::insert(BALL::String::const_iterator&,
> std::initializer_list&)'
> str_.insert(p, li);
>^
(...)
Info:
BALL::String::const_iterator is a typedef for std::string::const_iterator
> /usr/include/c++/5/bits/basic_string.h:1308:7: note: candidate: void
> std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>::iterator, std:: initializer_list<_Tp>) [with _CharT =
> char; _Traits = std::char_traits; _Alloc = std::allocator;
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator =
> __gnu_cxx::__normal_iterator >;
> typename __gnu_cxx::__alloc_traits __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other>::pointer = char*]
>insert(iterator __p, initializer_list<_CharT> __l)
>^
> /usr/include/c++/5/bits/basic_string.h:1308:7: note: no known conversion
> for argument 1 from 'BALL::String::const_iterator {aka
> __gnu_cxx::__normal_iterator
> >}' to 'std::__cxx11::basic_string::iterator {aka
> __gnu_cxx::__normal_iterator >}'
In essence this says:
(1) No matching function for
string::insert(string::const_iterator, initializer_list),
because (when trying the correct overload),
(2) Cannot convert from string::const_iterator to string::iterator
Which raises the question: Why does the compiler try to convert to a
non-const-iterator in the first place?
According to both cplusplus.com[1] and cppreference.com[2] the insert
function with an initializer_list as second parameter should take a
*const_*iterator directly.
I have condensed this into a simple test case (see attached string.cc)
and for me, this testcase fails in the same way as ball when called with
GCC.
Try it like this:
g++ -std=c++11 string.cc -o string && ./string
(long error message)
Now, with clang++ this fails too:
clang++ -std=c++11 string.cc -o string && ./string
(a bit shorter error message, but essentially the same)
However, if I try the example using clang's STL implementation (from
debian package libc++-dev) it builds *and runs* as expected:
clang++ -std=c++11 -stdlib=libc++ string.cc -o string && ./string
(outputs "Some new string")
I am not sure how to continue from here - this might be a bug in clang's
or gcc's std::string implementation, unportable usage from upstream, or
any number of other things. If you have access to other compilers, it
may help to test the snippet on them too and report the results.
For reference:
$ g++ -dumpversion
5.3.1
-> Does not compile, cannot convert const_iterator->iterator
-> libstdc++-5-dev 5.3.1-5
$ clang++ -dumpversion
4.2.1
-> Does not compile with default/gcc STL implementation
-> Compiles and runs with libc++-dev 3.7.0-1
I hope this helps in resolving this, or at least in figuring out *where*
the issue actually is located.
- Danny
[1]: http://www.cplusplus.com/reference/string/string/insert/
[2]: http://en.cppreference.com/w/cpp/string/basic_string/insert
#include
#include
using namespace std;
int main(){
string s = "Somestring";
string::const_iterator ci = s.cbegin()+4;
initializer_list il = { ' ', 'n', 'e', 'w' , ' ' };
s.insert(ci, il);
cout << s << endl;
return 0;
}
Bug#809136: borgbackup: Mention API incompatibilities in README
Hello everyone, after our discussions and the clarifications from anarcat, it seems that the only sensible way to solve this is by trying to inform the end-user as much as possible to help her/him make an informed decision whether they should use the 0.x software or wait for the 1.0 version. On future compat-breaking updates, I will take care to copy any relevant parts from upstream changelog to a NEWS.Debian file, to make sure they pop up during installation / get e-mailed to the admin, although that does of course not cover new installations. I have already split the Debian-READMEs into source[1] and end-user[2] and I tried to find a sensible wording for both. If you have better ideas, send patches! (feel free to spawn new branches on the collab-maint repository) Under the assumption that the enduser can be expected to at least read README.Debian, (upstream) README.rst, and NEWS.Debian upon updates, I believe that it should be appropriate to post stuff there. Please state whether you think this (write README and hope user actually reads it) is an appropriate solution to the compatibility problem, meaning we could close the bug this way. Cheers - Danny [1]: https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.source [2]: https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.Debian
Bug#809136: borgbackup: Mention API incompatibilities in README
Hi Antoine, On 01/13/2016 07:50 PM, anar...@debian.org wrote: > The readme is not quite accurate: *some* borg versions are actually > compatible across the network. It's only on the 0.29 boundary that there > is a problem. Is this[1] wording acceptable? Then I would prepare it for upload as 0.29.0-3, closing the bug. > It also refers to a non-existent backport, but i guess we can trust this > will come to fruitition soon. :) I was hoping that too, so this may be a bit optimistic. But I hope in case there is none, a user would report this as a bug (i.e. communicate with us) rather than installing in a non-managed directory. Cheers! - Danny [1]: https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/commit/?id=9f41b18ac0e53153cba88f8d5ae3b8ef21ae23fb
Bug#777791: [PATCH] ball: ftbfs with GCC-5
Hello Andreas, I have had some spare time and spent it on the ball package. I hope that helps you in getting the package back into Debian. Some notes regarding the patch: * I dropped the gcc5.patch, since it created an ambiguous overload of getline -- Upstream added one themselves in the meantime. * The patches in debian/patches/backports/ are all cherry-picked from the upstream git repository at github.com/BALL-project/ball -- their first line will tell you the commit ID. Take a look at the branch qt5_latest if they are not yet in master. They were created with git format-patch -1 , I hope that's all right. * The most problematic part was DOCKING/COMMON/poseClustering.h. It seems to break with boost-1.56, because it assumes a certain class is copyable that has been adapted to c++11's "move" idea. The commit that breaks it is https://github.com/boostorg/graph/commit/cb26ccf I have used a very crude workaround (I have defined a BOOST_* symbol suggesting that the compiler would not support moves), this needs to be properly ported to current boost by BALL upstream. Please try to get in contact with upstream, and have them properly port the code. * The upstream code is also not yet ready for libeigen3 version 3.3 (currently in beta) that drops some compatibility code. I added a Build-Conflicts to make the buildd's aware of that. This also needs to be ported by upstream. In order to build the package anyway, I had to add to my sources.list a snapshot.debian.org containing the older version (its header-only, so it's compiled into the binary and does not generate a run-time dependency). sources.list line containing a suitable old version: deb http://snapshot.debian.org/archive/debian/20150924T154447Z sid main * I activated the test suite in d/rules -- mainly because I was not sure if my crude workaround broke anything. On my test builds, the Socket_test sometimes™ failed. Maybe there is a race condition, I don't know. Could also be my old hardware bitrotting away... * Since I used the older libeigen, I set it as a "system" library in cmake, which prevents the compile log from generating warnings when eigen uses deprecated features (just distracted me while working on ball, feel free to drop that patch). The patch is based against b915af8eff, which was today (jan 26) the current master in the debian-med repository. After all this hacking, the package builds and the resulting .deb's seem usable to me, but I dont understand enough biochemics to make anything out of it : ) I can't tell myself if the patch is of acceptable quality, please have a look over it before adopting. Feedback would be much appreciated, this is my first non-trivial contribution. I hope this helps, - Danny diff --git a/debian/control b/debian/control index ceb15db..2b09efd 100644 --- a/debian/control +++ b/debian/control @@ -39,6 +39,7 @@ Build-Depends-Indep: doxygen, texlive-latex-recommended, texlive-fonts-recommended, texlive-latex-extra +Build-Conflicts: libeigen3-dev( >= 3.3~ ) Standards-Version: 3.9.6 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/ball.git Vcs-Git: git://anonscm.debian.org/debian-med/ball.git diff --git a/debian/patches/adapt-poseClustering-test-archive-boost1.58 b/debian/patches/adapt-poseClustering-test-archive-boost1.58 new file mode 100644 index 000..c5349c0 --- /dev/null +++ b/debian/patches/adapt-poseClustering-test-archive-boost1.58 @@ -0,0 +1,10 @@ +Subject: Adapt archive version number to 12 (boost1.58) + +The upstream boost::archive file was most likely compiled against a more +recent (version no. 13) serialization library, but boost1.58 (currently +highest in Debian) only has version no. 12 +--- a/source/TEST/data/PoseClustering_wardtree.dat b/source/TEST/data/PoseClustering_wardtree.dat +@@ -1 +1 @@ +-22 serialization::archive 13 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14 ++22 serialization::archive 12 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14 diff --git a/debian/patches/backports/FingerPrintSim-Fix-build.patch b/debian/patches/backports/FingerPrintSim-Fix-build.patch new file mode 100644 index 000..4f1eeec --- /de
Bug#777791: [PATCH] ball: ftbfs with GCC-5
Control: tags -1 patch
Hello Andreas,
I have taken on the ball FTBFS again, and have backported more fixes
from the github upstream. It can now compile on a fresh sid.
The patches 0001-missingSigned.patch and gcc5.diff are not necessary any
more, so I removed them, but I left nopsboxit.patch,
link_against_x11.patch and findsip.patch untouched.
I had to disable the building of the binary
source/APPLICATIONS/UTILITIES/assign_positions_from_template, but since
this binary was not previously installed into any package, I don't think
this is a problem.
All patches are taken from github upstream unless explicitly noted, and
I expect they will be included in the next release, but this may help
the Debian package back onto its feet right now.
The attached patch is based directly on master in collab-maint.
Cheers,
- Danny
From 93eb17ca031d7a5d225d8c33feacafe49b2675fb Mon Sep 17 00:00:00 2001
From: Danny Edel
Date: Sun, 10 Apr 2016 11:57:18 +0200
Subject: [PATCH] Rework patches for sid
This fixes FTBFS. Also, enable tests in d/rules.
---
debian/patches/0001-missingSigned.patch| 32 --
.../adjust-PoseClustering_Test-boost-1.58.patch| 13 +++
.../disable-assign-positions-from-template.patch | 10 ++
.../fix-FingerprintSimilarityClustering.patch | 54 +++
debian/patches/fix-PoseClustering_Test.patch | 17
...pilation-of-BinaryFingerprintMethods_test.patch | 81
.../fix-poseClustering-with-boost-1.60.patch | 108 +
debian/patches/fix-string-gcc5.patch | 73 ++
debian/patches/gcc5.diff | 18
debian/patches/series | 9 +-
debian/rules | 12 ++-
11 files changed, 373 insertions(+), 54 deletions(-)
delete mode 100644 debian/patches/0001-missingSigned.patch
create mode 100644 debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
create mode 100644 debian/patches/disable-assign-positions-from-template.patch
create mode 100644 debian/patches/fix-FingerprintSimilarityClustering.patch
create mode 100644 debian/patches/fix-PoseClustering_Test.patch
create mode 100644 debian/patches/fix-compilation-of-BinaryFingerprintMethods_test.patch
create mode 100644 debian/patches/fix-poseClustering-with-boost-1.60.patch
create mode 100644 debian/patches/fix-string-gcc5.patch
delete mode 100644 debian/patches/gcc5.diff
diff --git a/debian/patches/0001-missingSigned.patch b/debian/patches/0001-missingSigned.patch
deleted file mode 100644
index 6801495..000
--- a/debian/patches/0001-missingSigned.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From: Andreas Hildebrandt
-Date: Tue, 14 Aug 2012 17:14:31 +0200
-Subject: missingSigned
-
-===
- include/BALL/DATATYPE/hashGrid.h |2 +-
- source/DATATYPE/hashGrid.C |2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
a/include/BALL/DATATYPE/hashGrid.h
-+++ b/include/BALL/DATATYPE/hashGrid.h
-@@ -37,7 +37,7 @@ namespace BALL
- {
- namespace __private
- {
-- extern const char BALL_EXPORT neighbour_table_[27][3];
-+ extern const signed char BALL_EXPORT neighbour_table_[27][3];
- }
-
- template class HashGrid3;
a/source/DATATYPE/hashGrid.C
-+++ b/source/DATATYPE/hashGrid.C
-@@ -9,7 +9,7 @@ namespace BALL
- {
- namespace __private
- {
-- const char neighbour_table_[27][3] =
-+ const signed char neighbour_table_[27][3] =
- {
- { 0, 0, 0 }, { 0, 0, -1 }, { 0, 0, 1 },
- { 0, -1, -1 }, { 0, -1, 0 }, { 0, -1, 1 },
diff --git a/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch b/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
new file mode 100644
index 000..d4cd089
--- /dev/null
+++ b/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
@@ -0,0 +1,13 @@
+Subject: Adjust boost::archive for boost-1.58 version
+Author: Danny Edel
+
+The archive format of boost-1.58 (currently in sid) and the
+version 1.60, which the upstream patch is for, only differs
+in the "version" field.
+
+Delete this patch once 1.60 is in sid.
+--- a/source/TEST/data/PoseClustering_wardtree.dat
b/source/TEST/data/PoseClustering_wardtree.dat
+@@ -1 +1 @@
+-22 serialization::archive 13 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14
++22 serialization::archive 12 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.00
Bug#777791: [PATCH] ball: ftbfs with GCC-5
On Mon, 11 Apr 2016 17:54:03 +0200 Andreas Tille wrote: > Did you created a new repository on collab-maint for this purpose? > It seems you did not used a clone of the packaging Git > > git://anonscm.debian.org/debian-med/ball.git > Hi Andreas, sorry for the miswording -- I did use the git repository at the specified location, not collab-maint. If the patch didn't apply cleanly I can't say why. > since I tried to > > git am 0001-Rework-patches-for-sid.patch > > which resulted in several conflicts. I wonder whether you could > rather commit to the official packaging repository. To enable you > doing this I've added you to the Debian Med team. Thanks! I will submit there as soon as the group membership is through. I can already see that I'm added in the alioth webinterface, but "groups" on git.debian.org doesn't yet include scm_debian-med. Trying to push anyway gives: danny@debwork ~/git/debian-med/ball $ git push -v Pushing to git.debian.org:/git/debian-med/ball.git Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (13/13), done. Writing objects: 100% (13/13), 6.09 KiB | 0 bytes/s, done. Total 13 (delta 4), reused 0 (delta 0) remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To git.debian.org:/git/debian-med/ball.git = [up to date] pristine-tar -> pristine-tar = [up to date] upstream -> upstream ! [remote rejected] master -> master (unpacker error) updating local tracking ref 'refs/remotes/origin/pristine-tar' updating local tracking ref 'refs/remotes/origin/upstream' error: failed to push some refs to 'git.debian.org:/git/debian-med/ball.git' I will try to push again later tonight or tomorrow. I'm sure this is just an issue about the group membership update script not run yet. Cheers, - Danny signature.asc Description: OpenPGP digital signature
Bug#814579: dspdfviewer: FTBFS with xorg-1.18: Testsuite fails with floating point exception
Source: dspdfviewer Version: 1.14-2 Severity: serious Justification: fails to build from source (but built successfully in the past) After xorg got bumped to 1.18 in unstable, the testsuite started failing with "floating point exception" on the parts where xvfb-run is used to emulate a GUI. The Qt5 build worked in unstable before the xorg 1.18 bump, so the package testsuite will need to be adapted to the new version. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#814581: dspdfviewer: FTBFS: Errors while running CTest
Control: merge 814579 814581 On 13/02/16 09:41, Chris Lamb wrote: > Dear Maintainer, > > dspdfviewer fails to build from source in unstable/amd64: Hello Chris, thank you for reporting this. I have deduced that the most likely reason is the switch xorg 1.17->1.18. I am investigating how to fix this. The test output "Floating point exception" seems to suggest this is quite a low-level error. (The same source builds fine against sid snapshots from before the xorg 1.18 merge) I will report back on this issue here, just ignore the other one I opened. - Danny signature.asc Description: OpenPGP digital signature
Bug#814581: dspdfviewer: FTBFS: Errors while running CTest
Control: block -1 by 814607 Hi, since it seems to be not just dspdfviewer's test suite, but any qt5 program (even the qt5 examples) that brings the "Floating point exception" when run via xvfb-run, I have reported a bug against the xvfb package. Until this is fixed or a workaround known, we cannot use xvfb-run to execute the test suite. [upstream hat on] I'm thinking about reworking the Xvfb based environment to something more feature-complete, that can emulate two screens so I can test things like window alignment and screen-switching under the supported window managers. [Debian hat on] If I can't find a way to fix this, I'll probably have to disable the testsuite for Debian builds temporarily. Cheers, - Danny
Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831
Package: dspdfviewer Version: 1.14-2 Severity: serious Tags: upstream help Justification: fails to build from source (but built successfully in the past) On big-endian architectures, dspdfviewer currently fails to build from source. The error messages contain the decimal numbers, but "decoding" them to hex shows there is most likely an endianness issue somwehere inside: dec: 4287168392 != 4294936831 hex: FF 88 FF 88 != FF FF 88 FF dec: 4285537985 != 4280185087 hex: FF 70 1E C1 != FF 1E 70 FF Explanation: These colors are normally in ARGB (alpha, red, green, blue) format. For monitor pixels, Alpha is always FF (255). Swapping FF701EC1 gives C11E70FF, setting alpha to FF gives FF1E70FF which is exactly the created number. Tag "help": I do not have access to a real big-endian machine *with* an X-Server running to discern if this is actually a bug (it would look like really messed up colors) or a false positive in the test suite. I will try to reproduce and fix this with emulators like qemu, but this is of couse a really slow process and not 100% reliable (the emulator could be adding new endianness problems and/or hide an existing one). If you have a big-endian machine with X and are willing to help, please speak up : ) - Danny
Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831
On Sat, 27 Feb 2016 11:02:00 +0100 Danny Edel wrote: > On big-endian architectures, dspdfviewer currently fails to build from > source. I can reproduce this with cowbuilder-dist from the ubuntu-dev-tools package and the qemu-user-static emulator, with a mips chroot. However, the problem does *not occur on a jessie chroot*. Since the identical source produces different results on jessie vs. sid, this may be a regression in one of the third-party libraries linked. I will investigate further and report back here.
Bug#816782: borgbackup: FTBFS on hppa: test-suite fails at ArchiverTestCase.test_basic_functionality
Package: borgbackup Version: 1.0.0~rc2-3 Severity: serious Justification: fails to build from source (but built successfully in the past) On hppa, the borgbackup test suite failed on 1.0.0~rc2-3 [1] but built successfully on 1.0.0~rc2-1 [2]. This may be a regression in dependencies, since the during-build testsuite did not change, the only difference of those versions is in the autopkgtest and fuse in build-depends, which doesn't have anything to do with the failed test. [1]: https://buildd.debian.org/status/fetch.php?pkg=borgbackup&arch=hppa&ver=1.0.0~rc2-3&stamp=1457125572 [2]: https://buildd.debian.org/status/fetch.php?pkg=borgbackup&arch=hppa&ver=1.0.0~rc2-1&stamp=1456923438
Bug#807564: digikam: FTBFS, cannot find Marble
Hello List, I'm looking into this aswell, since I want to use digikam again and got some free time to fix it. I hope I can provide a source-patch in the next few days that allows the currently packaged version of digikam to build again. In case I get it to work, where do I send the patch? It would affect both #807564 and #802966 since they both say FTBFS (although for different reasons). Cheers, - Danny
Bug#807564: Fix "Can't find marble" FTBFS [patch]
Control: tags -1 patch Hi List, I've tried to reproduce the build failure and it turns out that the FindMarble.cmake file is in a path that is not in the default cmake module search path. If the search path is passed to cmake with EXTRA_CMAKE_ARGS, digikam compiles successfully again. Also the libsoprano-dev dependency is no longer a problem, because digikam build-depends on kdelibs5-dev, which (now?) depends on libsoprano-dev. I hope that helps in at least building digikam again, making it easier to look into the other remaining tickets. PS: If you test the patch locally, don't forget to increment digikam's version number! libstdc++6 in sid has a "Breaks: digikam-private-libs" on versions <= 4:4.4.0-1.1+b2 defined. I must add that although it compiles, it does *not* start out-of-the-box on my system, it now crashes with the following error message: *** Error in `digikam': realloc(): invalid old size: 0x00c21f80 *** Aborted Maybe someone with more C debugging skills can look into that? (or maybe it is an issue with my system) Cheers, - Danny diff -ru orig/digikam-4.4.0/debian/rules digikam-4.4.0/debian/rules --- orig/digikam-4.4.0/debian/rules 2014-01-18 00:19:58.0 +0100 +++ digikam-4.4.0/debian/rules 2015-12-13 14:39:07.711699472 +0100 @@ -12,6 +12,9 @@ EXTRA_CMAKE_ARGS += -DDIGIKAMSC_USE_PRIVATE_KDEGRAPHICS=OFF endif +# Location of FindMarble.cmake +EXTRA_CMAKE_ARGS += -DCMAKE_MODULE_PATH=/usr/share/marble/cmake + %: dh $@ --with kde --parallel
Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831
On Sat, 27 Feb 2016 12:27:44 +0100 Danny Edel wrote: > I will investigate further and report back here. I cannot determine the exact cause why it fails on big-endian emulation. Also, trying to load any GUI through the emulator just results in a blank window, so I cannot even check if the resulting binary is all right (false-positive). My best guess is that Qt uses OpenGL to accelerate drawing, which cannot be emulated correctly, meaning this could be a test failure without anything being wrong. As a temporary workaround, I have disabled unittests on big-endian hardware in v1.15-1 (to be uploaded today), until someone with access to a hardware machine with X11 can help in checking the exact situation. [help needed] If you have a big-endian machine with X11 running, please try executing the software and check if the resulting UI looks okay or the colors are messed up -- seeing as how blue was always 0xFF, all output should look blue-tainted if the test suite diagnosed a problem correctly. If you want to donate some time to this, you can re-activate the unittests by appending -DRunUnitTestsOnBigEndian=ON to the dh_auto_configure call in d/rules. - Danny signature.asc Description: OpenPGP digital signature
