Bug#853443: hidrd: ftbfs with GCC-7
On Mon, 4 Dec 2017 12:50:24 +0200 Juhani Numminen wrote: > Control: tags -1 patch fixed-upstream > > On Mon, 4 Dec 2017 10:23:34 +0200 Juhani Numminen > wrote: > > Upstream has committed some GCC-7-related fixes. > > https://github.com/DIGImend/hidrd/commit/7e94881 > > https://github.com/DIGImend/hidrd/commit/e126127 > > I had a successful amd64 build with the two attached patches. > > Cheers, > Juhani The problem still remains on ppc64el with gcc version 8.2.0
Bug#870051: qile FTBFS: test_thermalsensor_regex_compatibility failure
Hello,
Just wondering why this test seem to have passed in 0.10.6-3 (sid) and
not any more ?
As this test is failing on most arch, shouldn't we disable it ?
Thanks
On Sat, 29 Jul 2017 12:43:02 +0300 Adrian Bunk wrote:
> Source: qtile
> Version: 0.10.7-2
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=qtile&suite=sid
>
> ...
> === FAILURES
> ===
> test_thermalsensor_regex_compatibility
>
>
> def test_thermalsensor_regex_compatibility():
> > sensors = ThermalSensor()
>
> test/test_widget.py:62:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> libqtile/widget/sensors.py:73: in __init__
> temp_values = self.get_temp_sensors()
> libqtile/utils.py:202: in wrapper
> return_value = func(*args, **kwargs)
> libqtile/widget/sensors.py:93: in get_temp_sensors
> sensors_out = self.call_process(command)
> libqtile/widget/base.py:262: in call_process
> output = subprocess.check_output(command, **kwargs)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
>
> input = None, timeout = None, check = True, popenargs = (['sensors'],)
> kwargs = {'stdout': -1}, process =
> stdout = b'', stderr = None, retcode = 1
>
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
>
> There is an optional argument "input", allowing you to
> pass a string to the subprocess's stdin. If you use this argument
> you may not also use the Popen constructor's "stdin" argument, as
> it will be used internally.
>
> The other arguments are the same as for the Popen constructor.
>
> If universal_newlines=True is passed, the "input" argument must be a
> string and stdout/stderr in the returned object will be strings
> rather than
> bytes.
> """
> if input is not None:
> if 'stdin' in kwargs:
> raise ValueError('stdin and input arguments may not both be
> used.')
--
Thierry Fauck @ fr.ibm.com
Bug#922698: kcov: FTBFS on sid : error: 'SIGUNUSED' was not declared in this scope
Package: kcov Version: 25+dfsg-1 Severity: serious Tags: sid buster Compilation usually fails with messages cd /<>/kcov-25+dfsg/obj-i686-linux-gnu/src && /usr/bin/c++ -I/<>/kcov-25+dfsg/src/include -I/usr/include/i386-linux-gnu -std=c++0x -g -Wall -D_GLIBCXX_USE_NANOSLEEP -DKCOV_LIBRARY_PREFIX=/tmp -o CMakeFiles/kcov.dir/engines/ptrace.cc.o -c /<>/kcov-25+dfsg/src/engines/ptrace.cc /<>/kcov-25+dfsg/src/engines/ptrace.cc: In member function 'const kcov::IEngine::Event Ptrace::waitEvent()': /<>/kcov-25+dfsg/src/engines/ptrace.cc:337:17: error: 'SIGUNUSED' was not declared in this scope int sigill = SIGUNUSED; ^ /<>/kcov-25+dfsg/src/engines/ptrace.cc:337:17: note: suggested alternative: 'SI_USER' int sigill = SIGUNUSED; ^ SI_USER src/CMakeFiles/kcov.dir/build.make:186: recipe for target 'src/CMakeFiles/kcov.dir/engines/ptrace.cc.o' failed make[3]: *** [src/CMakeFiles/kcov.dir/engines/ptrace.cc.o] Error 1 make[3]: Leaving directory '/<>/kcov-25+dfsg/obj-i686-linux-gnu' CMakeFiles/Makefile2:90: recipe for target 'src/CMakeFiles/kcov.dir/all' failed
Bug#917644: FTBFS: segmentation faults in test suite
On Mon, 7 Jan 2019 16:49:41 + Steve McIntyre wrote: > Hi Matthew, > > On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote: > >If it is just the `world` regression tests that are failing, then it > >is almost certainly due to save/restore world being incompatible with > >ASLR; see http://mlton.org/MLtonWorld#_notes. Perhaps Debian > >arm64-linux has gained ASLR since the last time the regression suite > >was run on this platform? In any case, you'll notice that the `world` > >regression tests are explicitly whitelisted (i.e., these tests failing > >do not cause a failure exit status from the regression script) because > >of this issue. > As this bug is not specifically opened for one arch, I also want to mention it fails on ppc64el. I see the sequence testing wordn-array testing world1 2c2,3 < I am the clone --- > unhandled exception: Fail: child failed > Nonzero exit status. world1: difference with -type-check true testing world2 1c1,2 < 30 --- > unhandled exception: Fail: child failed > Nonzero exit status. world2: difference with -type-check true testing world3 1c1,2 < caught foo --- > unhandled exception: Fail: child failed > Nonzero exit status. world3: difference with -type-check true testing world4 4,6c4,5 < between saves < after saves < after saves --- > unhandled exception: Fail: child failed > Nonzero exit status. world4: difference with -type-check true testing world5 2c2,3 < success --- > unhandled exception: Fail: child failed > Nonzero exit status. world5: difference with -type-check true testing world6 1,4c1 < ./world6 < a < b < c --- > Segmentation fault world6: difference with -type-check true testing DLXSimulator testing barnes-hut testing boyer but then it fails with message: testing mlprof make[1]: *** [Makefile:391: check] Error 1 make[1]: Leaving directory '/<>' make: *** [/usr/share/cdbs/1/class/makefile.mk:113: debian/stamp-makefile-check] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 when of course we properly have the messages make -C . check make[1]: Entering directory '/<>' ./bin/regression whitelisting real... whitelisting world1... whitelisting world2... whitelisting world3... whitelisting world4... whitelisting world5... whitelisting world6... MLton 20180207 flags = -type-check true Thanks
Bug#917644: FTBFS: segmentation faults in test suite
On Tue, 19 Feb 2019 16:50:00 +0100 "Thierry fa...@linux.ibm.com" wrote: > On Mon, 7 Jan 2019 16:49:41 + Steve McIntyre wrote: > > Hi Matthew, > > > > On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote: > > >If it is just the `world` regression tests that are failing, then it > > >is almost certainly due to save/restore world being incompatible with > > >ASLR; see http://mlton.org/MLtonWorld#_notes. Perhaps Debian > > >arm64-linux has gained ASLR since the last time the regression suite > > >was run on this platform? In any case, you'll notice that the `world` > > >regression tests are explicitly whitelisted (i.e., these tests failing > > >do not cause a failure exit status from the regression script) because > > >of this issue. > > > As this bug is not specifically opened for one arch, I also want to > mention it fails on ppc64el. I see the sequence > testing wordn-array > testing world1 > 2c2,3 > < I am the clone > --- > > unhandled exception: Fail: child failed > > Nonzero exit status. > world1: difference with -type-check true > testing world2 > 1c1,2 > < 30 > --- > > unhandled exception: Fail: child failed > > Nonzero exit status. > world2: difference with -type-check true > testing world3 > 1c1,2 > < caught foo > --- > > unhandled exception: Fail: child failed > > Nonzero exit status. > world3: difference with -type-check true > testing world4 > 4,6c4,5 > < between saves > < after saves > < after saves > --- > > unhandled exception: Fail: child failed > > Nonzero exit status. > world4: difference with -type-check true > testing world5 > 2c2,3 > < success > --- > > unhandled exception: Fail: child failed > > Nonzero exit status. > world5: difference with -type-check true > testing world6 > 1,4c1 > < ./world6 > < a > < b > < c > --- This pad is hosted in Toulouse LTC lab. Created at 2019-02-19 09:45:56. Hi, I have run make check without world tests and result is code 1 because of failing tests on some architectures testing mlton.overload testing mlton.share 1c1 < size of a is 1600 --- > size of a is 2408 102c102 < size of a is 484 --- > size of a is 920 testing size2 2,23c2,23 < The size of an int list of length 4 is = 48 bytes. < The size of a string of length 10 is = 24 bytes. < The size of an int array of length 10 is = 52 bytes. < The size of a double array of length 10 is = 92 bytes. < The size of a (word32 * double) array of length 10 is = 132 bytes. < The size of a (word32 * word32 * double) array of length 10 is = 172 bytes. < The size of a (word64 * double) array of length 10 is = 172 bytes. < The size of a (word16 * double) array of length 10 is = 132 bytes. < The size of a word64 array of length 10 is = 92 bytes. < The size of a (word32 * word64) array of length 10 is = 132 bytes. < The size of a (word32 * word32 * word64) array of length 10 is = 172 bytes. < The size of a (word64 * word64) array of length 10 is = 172 bytes. < The size of a (word16 * word64) array of length 10 is = 132 bytes. < The size of an array of length 10 of 2-ples of ints is = 92 bytes. < The size of an array of length 10 of 2-ples of (shared) ints is = 92 bytes. < The size of an array of length 10 of arrays of length 20 of ints is = 972 bytes. < The size of an array of length 10 of (shared) arrays of length 20 of ints is = 144 bytes. < The size of an array of length 10 of tuples of word16 * (arrays of length 20 of ints) is = 1012 bytes. < The size of an array of length 10 of tuples of word32 * (arrays of length 20 of ints) is = 1012 bytes. < The size of an array of length 10 of tuples of word64 * (arrays of length 20 of ints) is = 1052 bytes. < The size of an array of length 10 of tuples of real32 * (arrays of length 20 of ints) is = 1012 bytes. < The size of an array of length 10 of tuples of real64 * (arrays of length 20 of ints) is = 1052 bytes. --- > The size of an int list of length 4 is = 96 bytes. > The size of a string of length 10 is = 40 bytes. > The size of an int array of length 10 is = 64 bytes. > The size of a double array of length 10 is = 104 bytes. > The size of a (word32 * double) array of length 10 is = 184 bytes. > The size of a (word32 * word32 * double) array of length 10 is = 184 bytes. > The size of a (word64 * double) array of length 10 is = 184 bytes. > The size of a (word16 * double) array of length 10 is = 184 bytes. testing size3 1c1,114 < size3.$arch-$os.ok missing --- > The size of unit is = 0 bytes. > The size of unit * unit is = 0 bytes. > The size of bool is = 0 bytes. > The size of bool * bool is = 16 bytes. > The size of day is = 0 bytes. > The size of day * day is = 0 bytes. > The size of a char is = 0 bytes. > The size of a char * char is = 0 bytes. > The size of a word8 is = 0 bytes. > The size of a word8 * word8 is = 0 bytes. > The size of a word16 is = 0 bytes. -- Thierry Fauck @ fr.ibm.com
Bug#888733: hyantesite FTBFS on most architectures: test failures
On Mon, 29 Jan 2018 11:47:06 +0200 Adrian Bunk wrote: > Source: hyantesite > Version: 1.3.0-2 > Severity: serious > > hyantesite FTBFS on most architectures with varying test failures: > > https://buildd.debian.org/status/package.php?p=hyantesite > > Since the tests are failing because (apparently) the result of float 0 is being minus signed I suspect this is related to arch representation of some signed variables during calculation. Any guess ? here is an example of the result of the comparison diff test/two_circles.out /tmp/libhypersmooth.zVpJKq 41c41 < -1.00 0.00 0.00 --- > -1.00 -0.00 0.00 122c122 < -0.975000 0.00 0.00 --- > -0.975000 -0.00 0.00
Bug#909861: shark FTBFS on i386 with gcc 8
On Sat, 29 Sep 2018 20:48:49 +0300 Adrian Bunk wrote: > Source: shark > Version: 3.1.4+ds1-1 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/shark.html > > ... > 57/160 Test #67: Trainers_MissingFeatureSvmTrainer ***Failed > 0.52 sec > Running 2 test cases... > ./Test/Algorithms/Trainers/MissingFeatureSvmTrainerTests.cpp(165): error: in > "Algorithms_Trainers_MissingFeatureSvmTrainerTests/MissingFeatures": check > test::verifyVectors(output1, output2) has failed. index:0, seen:1.23556e+267, > expected:-5.83284e+118 > > *** 1 failure is detected in the test module > "MissingFeaturesSvmTrainerTestModule" > ... > 99% tests passed, 1 tests failed out of 160 > > Total Test time (real) = 697.78 sec > > The following tests FAILED: >67 - Trainers_MissingFeatureSvmTrainer (Failed) > Errors while running CTest > make[2]: *** [Makefile:143: test] Error 8 > > This test is also failing on amd64 and ppc64el ... and may be others !
Bug#844778: clsync FTBFS on !x86: error: '__NR_select' undeclared here
On Sat, 19 Nov 2016 01:09:28 +0200 Adrian Bunk wrote: > Source: clsync > Version: 0.4.2-1 > Severity: serious > > https://buildd.debian.org/status/package.php?p=clsync&suite=sid > > ... > In file included from privileged.c:64:0: > privileged.c:88:34: error: '__NR_select' undeclared here (not in a function) > BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_##syscall, 0, 1), \ > ... > > Depending on arch you have different __NR_ functions not present - for example, __NR_alarm or __NR_shmdt
Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code
Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as compiling on buster fails with following error - what do we do ? Thanks BT check (recess model): prob vs. prob_fv OK 2c2 < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 437.583 -567.388 435.04 1.75239 --- > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 437.583 -567.387 435.04 1.75239 BT check (2df model): prob vs. prob_fv FAILED FAIL test_bt.sh (exit status: 1) - On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk wrote: > Source: probabel > Version: 0.5.0+dfsg-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0 > > ... > FAIL: test_bt > = > > Analysing BT... > BT check: dose vs. dose_fv OK > BT check (add model): prob vs. prob_fv OK > BT check (domin model): prob vs. prob_fv OK > BT check (over_domin model): prob vs. prob_fv OK > BT check (recess model): prob vs. prob_fv OK > 2c2 > < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 > 437.583 -567.387 435.04 1.75239 > --- > > rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 > > 437.583 -567.388 435.04 1.75239 > BT check (2df model): prob vs. prob_fv FAILED > FAIL test_bt.sh (exit status: 1) > > > Testsuite summary for ProbABEL 0.5.0 > > # TOTAL: 11 > # PASS: 10 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > See checks/test-suite.log > Please report to genabel-de...@r-forge.wu-wien.ac.at > > make[4]: *** [Makefile:713: test-suite.log] Error 1 > > > I suspect this might be a problem with the NEON code in Eigen 3, > and the fact that this can be fixed with the following workaround > makes that even more probable: > > --- debian/rules.old 2019-01-09 15:07:11.950823327 + > +++ debian/rules 2019-01-09 15:17:23.280539016 + > @@ -6,6 +6,10 @@ > > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > > +ifeq ($(DEB_HOST_ARCH),arm64) > + export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd > +endif > + > include /usr/share/dpkg/default.mk > > # Location of the example files, will be converted to the > >
Bug#919189: Fwd: probabel FTBFS on arm64, likely due to Eigen 3 NEON code
Hi, Thanks for pointing out that my analysis wasn't good - the arm patch doesn't change anything for ppc64el (which make sense whatsoever) - the problem on ppc64el is similar to the one on arm except the test value are opposite ! ( which was confusing). So what do we need to do ? expect that someone with a better expertise help going though it ? ( can you confirm we stay with that bug for both arch or do we need to open one for ppc64el ?) Thanks On 02/02/2019 07:15, Andreas Tille wrote: > Hi, > > I think these are just rounding errors due to different representation of > floating point numbers. Relaxing the precision of the test would solve > the problem (but I have no idea about the test suite and so do not know > how to implement this). > > What I do also not understand why a fix that only occures on arm64 now > has an influence on ppc64el. Did ppc64el compiled fine for version > 0.5.0+dfsg-1 (without that fix)? > > Kind regards > > Andreas. > > On Fri, Feb 01, 2019 at 04:41:04PM +0100, Thierry fa...@linux.ibm.com wrote: >> Unfortunately the workaround mentioned for arm64 breaks ppc64el arch as >> compiling on buster fails with following error - what do we do ? >> Thanks >> >> >> BT check (recess model): prob vs. prob_fv OK >> 2c2 >> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 >> 544.518 437.583 -567.388 435.04 1.75239 >> --- >>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 >> 544.518 437.583 -567.387 435.04 1.75239 >> BT check (2df model): prob vs. prob_fv >> FAILED >> FAIL test_bt.sh (exit status: 1) >> - >> >> >> >> On Sun, 13 Jan 2019 16:37:02 +0200 Adrian Bunk wrote: >>> Source: probabel >>> Version: 0.5.0+dfsg-1 >>> Severity: serious >>> Tags: ftbfs >>> >>> https://buildd.debian.org/status/fetch.php?pkg=probabel&arch=arm64&ver=0.5.0%2Bdfsg-1&stamp=1538603399&raw=0 >>> >>> ... >>> FAIL: test_bt >>> = >>> >>> Analysing BT... >>> BT check: dose vs. dose_fv OK >>> BT check (add model): prob vs. prob_fv OK >>> BT check (domin model): prob vs. prob_fv OK >>> BT check (over_domin model): prob vs. prob_fv OK >>> BT check (recess model): prob vs. prob_fv OK >>> 2c2 >>> < rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 >>> 437.583 -567.387 435.04 1.75239 >>> --- >>>> rs7247199 GAC A 0.5847 0.415 0.9299 0.8666 200 0.333517 19 204938 544.518 >>>> 437.583 -567.388 435.04 1.75239 >>> BT check (2df model): prob vs. prob_fv >>> FAILED >>> FAIL test_bt.sh (exit status: 1) >>> >>> >>> Testsuite summary for ProbABEL 0.5.0 >>> >>> # TOTAL: 11 >>> # PASS: 10 >>> # SKIP: 0 >>> # XFAIL: 0 >>> # FAIL: 1 >>> # XPASS: 0 >>> # ERROR: 0 >>> >>> See checks/test-suite.log >>> Please report to genabel-de...@r-forge.wu-wien.ac.at >>> >>> make[4]: *** [Makefile:713: test-suite.log] Error 1 >>> >>> >>> I suspect this might be a problem with the NEON code in Eigen 3, >>> and the fact that this can be fixed with the following workaround >>> makes that even more probable: >>> >>> --- debian/rules.old2019-01-09 15:07:11.950823327 + >>> +++ debian/rules2019-01-09 15:17:23.280539016 + >>> @@ -6,6 +6,10 @@ >>> >>> export DEB_BUILD_MAINT_OPTIONS=hardening=+all >>> >>> +ifeq ($(DEB_HOST_ARCH),arm64) >>> + export DEB_CXXFLAGS_MAINT_APPEND = -march=armv8-a+nosimd >>> +endif >>> + >>> include /usr/share/dpkg/default.mk >>> >>> # Location of the example files, will be converted to the >>> >>> >> ___ >> Debian-med-packaging mailing list >> debian-med-packag...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Thierry Fauck @ fr.ibm.com
Bug#983843: xrdp FTBFS on several architectures
At least that problem on ppc machines is due to fact that ppc64el is not taken in account properly A patch could be diff xrdp-0.9.12/common/arch.h xrdp-bad/common/arch.h 64a65,70 > #if defined(__LITTLE_ENDIAN__) > #define L_ENDIAN > #else > #define B_ENDIAN > #endif > 68,69c74,75 < (defined(__PPC__) && defined(__BIG_ENDIAN__)) || \ < (defined(__ppc__) && defined(__BIG_ENDIAN__)) --- > defined(__PPC__) || \ > defined(__ppc__) 82,83c88 < (defined(__PPC__) && defined(__BIG_ENDIAN__)) || \ < (defined(__ppc__) && defined(__BIG_ENDIAN__)) --- > defined(__PPC__) || defined(__ppc__)
Bug#918572: check FTBFS on ppc*: test failure
On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk wrote: Source: check Version: 0.12.0-0.1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=check ... FAIL: check_check_export FAIL: check_check PASS: test_output.sh PASS: test_check_nofork.sh PASS: test_check_nofork_teardown.sh PASS: test_xml_output.sh PASS: test_log_output.sh PASS: test_set_max_msg_size.sh PASS: test_tap_output.sh Check 0.12.0: tests/test-suite.log # TOTAL: 9 # PASS: 7 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 (powerpcspe builds with nocheck) Could you recheck compilation as my last test with gcc-9 on SID passes. Thx -- Thierry Fauck @ fr.ibm.com
Bug#918572: check FTBFS on ppc*: test failure
Hello, Thanks for pointing out there is still the issue. I realized my test was using version 0.10.0-3 instead of 0.12.0-0.1 ! As one of the failing test: ../../tests/check_check_master.c:749:F:Core Tests:test_check_all_ftypes:125: For test 125:Simple Tests:test_ck_assert_ldouble_eq_tol failure type wrong, expected 2 but got 1 I wonder if it is not related to the double memory representation on ppc64el ... usual story of 64bits-128bits may be I Will try to investigate again Thanks On 9/22/2019 8:32 PM, Boyuan Yang wrote: I submitted a self-service giveback request and had this package rebuilt on ppc64el. It is still failing with GCC 9. Looks like further investigation is needed. https://buildd.debian.org/status/package.php?p=check Thanks, Boyuan Yang On Fri, 20 Sep 2019 09:57:02 +0200 "Thierry fa...@linux.ibm.com" < thie...@linux.ibm.com> wrote: On Mon, 07 Jan 2019 15:54:46 +0200 Adrian Bunk wrote: Source: check Version: 0.12.0-0.1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=check ... FAIL: check_check_export FAIL: check_check PASS: test_output.sh PASS: test_check_nofork.sh PASS: test_check_nofork_teardown.sh PASS: test_xml_output.sh PASS: test_log_output.sh PASS: test_set_max_msg_size.sh PASS: test_tap_output.sh Check 0.12.0: tests/test-suite.log # TOTAL: 9 # PASS: 7 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 (powerpcspe builds with nocheck) Could you recheck compilation as my last test with gcc-9 on SID passes. Thx -- Thierry Fauck @ fr.ibm.com -- Thierry Fauck @ fr.ibm.com
Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2
Source: tcpdump Version: 4.9.3-1 Severity: serious https://buildd.debian.org/status/logs.php?pkg=tcpdump&arch=ppc64el&suite=sid --- 1 tests failed 441 tests passed Failed test: ikev2pI2 41c41 < (v2auth: len=196 method=rsasig authdata=() )) --- > (v2auth: len=196 method=rsasig authdata=(9d7686de6fabda36c4b374135ccca0c4596fe7636e19ee71ea7d276b4230948ab529651ba1dbec39e85e506ff90b48a57611be386a5867beccde9c9971587907251df58f0c46b473d9f0abc308eb85482f08383d) )) This is similar to bug #873377 which was supposed to be fixed in V 4.9.1-2 - logs show that for v4.9.1-2 and -3 test was not run - then it was failing but not reported as an error for the global count of success !
Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined
Hello I've personally always used __powerpc__ . Here is my reference, very useful for all arch related defines : https://wiki.debian.org/ArchitectureSpecificsMemo Cheers Thierry I've Cc:-ed tille as his was the most recent upload. Let me know if you'd like me to NMU with a s/__POWERPC__/__powerpc__/. Cheers, Olly
Bug#864423: Software RAID is not activated at boot time
So what about adding case $Node_Name in /dev/*) Raid_Name=$(dmraid -i -r -cr $Node_Name | grep -vi "No RAID disks" > | grep -vi "formats discovered") break;; esac ou similar ? > > As $Node_Name already contains "/dev", in my case dmraid is called with > parameters /dev/dev/sdb and /dev/dev/sda . > > Regards > Christoph > > Best regards / Cordialement Thierry
Bug#878843: util-linux: fsck on btrfs /home hangs, stalling boot
On Wed, 18 Oct 2017 08:42:32 -0400 Phil Susi wrote: > On 10/18/2017 3:54 AM, Bernhard Schmidt wrote: > > Accessing /home leads to a blocked process. The reason is that (for > > numerous years, due to reasons I don't remember) I had > > x-systemd.automount in my fstab for /home > > That makes sense. Now I wonder why is fsck trying to open /home? You > run it on the block device; it should not know or care that the > filesystem is normally mounted in /home. > > Hello, As this bug has not been updated for more than a year do we expect any update or do we consider it is irrelevant ? Thanks for your update
Bug#884128: libical: don't release with buster
Hello, As currently we have (for most of the platforms) $ apt-cache madison libical2 libical2 | 2.0.0-4+b2 | http://ftp.fr.debian.org/debian buster/main amd64 Packages libical |2.0.0-4 | http://ftp.fr.debian.org/debian buster/main Sources What do we do with that bug ? Thanks On Wed, 8 Aug 2018 10:39:14 +0200 Emilio Pozuelo Monfort wrote: > On 08/08/18 09:33, Niels Thykier wrote: > > Control: tags -1 moreinfo > > > > On Mon, 11 Dec 2017 19:43:59 +0100 Emilio Pozuelo Monfort > > wrote: > >> Source: libical > >> Version: 2.0.0-1 > >> Severity: serious > >> > >> Hi, > >> > >> We have src:libical3 now, so libical2 should be dropped before the > >> freeze. We shouldn't need to release buster with both libical 2 and 3. > >> Filing this bug so we don't forget about that. > >> > >> Emilio > >> > >> [...] > > Hi Emilio, > > > > We are getting "close" to the transition freeze. If it is still the > > plan to remove libical from Debian buster, please start filing bugs > > against the (remaining) reverse dependencies and have them fixed. > > That's basically kdepimlibs, as cyrus-imapd is not in testing and kmymoney is > already fixed in experimental and just needs an upload to sid. > > kdepimlibs may not be easy though as disabling libical will probably disable > some libs that may be used by rdeps. Someone needs to look at that. I have > just > opened a bug for it and made it block this one. > > Cheers, > Emilio > > -- Thierry Fauck @ fr.ibm.com
Bug#876905: qtwebkit should not be release with buster
On Tue, 26 Sep 2017 22:15:12 +0300 Adrian Bunk wrote: > Source: qtwebkit > Version: 2.3.4.dfsg-9.1 > Severity: serious > Tags: buster sid > > qtwebkit should not be release with buster > (RC bugs are already open against all r-deps). > > As version 2.3.4.dfsg-10 is part of buster what do we do with that bug ? thanks
Bug#909750: applications tries to write to /usr/* directories via libfontconfig1
On Sun, 11 Nov 2018 12:04:06 +0100 Jakub Wilk wrote: > * Laurent Bigonville , 2018-11-11, 11:18: > >Do you have any .uuid files in these directories? > > IIRC, I didn't have any back then. > > >Can you try to run "fc-cache -s -f -v" (as root) and see if it helps. > > I think I upgraded some font package, which triggered fontconfig, which > ran the aforementioned command. Yes, it did help. > > >What file system do you use for /usr/share/fonts/? > > ext4 > > >The only occurrence I'm seeing on my system is: > > > >openat(AT_FDCWD, "/usr/lib/firefox/fonts/.uuid.TMP-EWjEq0", > >O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = -1 EACCES (Permission denied) > > Now it's the only occurrence for me, too. > > -- > Jakub Wilk > Hello, With current packages I don't see any more issues of openat() EACESS(...) when tracing firefox-bin Can you confirm and state about that bug Thanks
Bug#916145: closure-compiler: Not working with recent JS code
Hello, Is that bug still valid with current version 20130227+dfsg1-10 ? thanks On Mon, 10 Dec 2018 17:42:12 +0100 Roland Gruber wrote: > Package: closure-compiler > Version: 20130227+dfsg1-9 > Severity: important > > Dear Maintainer, > > the current version is so old that it got incompatible with recent JS code. > E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors. > > Please either update the tool or remove it from the archive. This is now > 5 years in unmaintained state. > > > -- System Information: > Debian Release: 9.6 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages closure-compiler depends on: > ii default-jre-headless [java6-runtime-headless]2:1.8-58 > ii java-wrappers0.1.28 > ii libclosure-compiler-java 20130227+dfsg1-9 > ii openjdk-8-jre-headless [java6-runtime-headless] 8u181-b13-2~deb9u1 > ii oracle-java8-jdk [java6-runtime-headless]8u77 > > closure-compiler recommends no packages. > > closure-compiler suggests no packages. > > -- no debconf information > > -- Thierry Fauck @ fr.ibm.com
