Unhandled Task Failure Read: Connection Reset by Peer Econnreset Julia
Debian Bug report logs - #816980
julia: Please do not use more CPUs than available.
Reported by: Santiago Vila <sanvila@debian.org>
Appointment: Dominicus, 6 Mar 2022 23:30:10 UTC
Severity: normal
Plant in version julia/0.4.iii-1
Done: Santiago Vila <sanvila@unex.es>
Bug is archived. No further changes may be made.
Toggle useless messages
Study forwarded to debian-bugs-dist@lists.debian.org, sanvila@debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Sun, 06 Mar 2022 23:30:thirteen GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@debian.org>:
New Bug written report received and forwarded. Copy sent to sanvila@debian.org, Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Sun, 06 Mar 2022 23:30:thirteen GMT) (full text, mbox, link).
Message #v received at submit@bugs.debian.org (full text, mbox, answer):
Package: src:julia Version: 0.4.iii-ane User: sanvila@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: -------------------------------------------------------------------------------- [...] debian/rules build-indep dh build-indep --parallel --with=sphinxdoc dh_testdir -i -O--parallel dh_update_autotools_config -i -O--parallel dh_auto_configure -i -O--parallel debian/rules override_dh_auto_build make[ane]: Inbound directory '/<<PKGBUILDDIR>>' dh_auto_build -- USE_SYSTEM_LIBUNWIND=1 USE_SYSTEM_PCRE=1 USE_SYSTEM_BLAS=1 USE_SYSTEM_LAPACK=ane USE_BLAS64=0 USE_SYSTEM_FFTW=1 USE_SYSTEM_GMP=1 USE_SYSTEM_ARPACK=one USE_SYSTEM_MPFR=1 USE_SYSTEM_SUITESPARSE=1 USE_SYSTEM_OPENSPECFUN=one USE_SYSTEM_PATCHELF=one USE_SYSTEM_DSFMT=1 USE_SYSTEM_UTF8PROC=one USE_SYSTEM_LIBGIT2=i USE_LLVM_SHLIB=one USE_SYSTEM_LLVM=1 LLVM_VER=three.7 LLVM_CONFIG=/usr/bin/llvm-config-3.7 VERBOSE=1 NO_GIT=1 MULTIARCH_INSTALL=ane MULTIARCH=x86_64-linux-gnu sysconfdir=/etc prefix=/usr DESTDIR=debian/tmp/ MARCH=x86-64 USE_SYSTEM_OPENLIBM=1 LIBBLAS=-lopenblas LIBBLASNAME=libopenblas LIBLAPACK=-lopenblas LIBLAPACKNAME=libopenblas brand -j1 USE_SYSTEM_LIBUNWIND=1 USE_SYSTEM_PCRE=1 USE_SYSTEM_BLAS=ane USE_SYSTEM_LAPACK=1 USE_BLAS64=0 USE_SYSTEM_FFTW=1 USE_SYSTEM_GMP=1 USE_SYSTEM_ARPACK=ane USE_SYSTEM_MPFR=one USE_SYSTEM_SUITESPARSE=one USE_SYSTEM_OPENSPECFUN=1 USE_SYSTEM_PATCHELF=ane USE_SYSTEM_DSFMT=ane USE_SYSTEM_UTF8PROC=1 USE_SYSTEM_LIBGIT2=1 USE_LLVM_SHLIB=1 USE_SYSTEM_LLVM=i LLVM_VER=3.7 LLVM_CONFIG=/usr/bin/llvm-config-3.seven VERBOSE=one NO_GIT=one MULTIARCH_INSTALL=1 MULTIARCH=x86_64-linux-gnu sysconfdir=/etc prefix=/usr DESTDIR=debian/tmp/ MARCH=x86-64 USE_SYSTEM_OPENLIBM=1 LIBBLAS=-lopenblas LIBBLASNAME=libopenblas LIBLAPACK=-lopenblas LIBLAPACKNAME=libopenblas make[two]: Inbound directory '/<<PKGBUILDDIR>>' Warning: git information unavailable; versioning information limited make[3]: Entering directory '/<<PKGBUILDDIR>>/deps' [... snipped ...] signal (xi): Segmentation mistake Worker 3 terminated. From worker iii: [1m*[0m [31mlinalg/qr [0mERROR (unhandled task failure): readcb: connectedness reset by peer (ECONNRESET) signal (11): Sectionalisation fault Worker 4 terminated. From worker 4: [1m*[0m [31mlinalg/dense [0mERROR (unhandled task failure): readcb: connection reset by peer (ECONNRESET) signal (11): Segmentation fault Worker v terminated. From worker v: [1m*[0m [31mlinalg/matmul [0mERROR (unhandled task failure): readcb: connectedness reset by peer (ECONNRESET) signal (11): Segmentation fault Worker 7 terminated. From worker vii: [1m*[0m [31mlinalg/special [0mERROR (unhandled task failure): EOFError: read end of file signal (11): Segmentation error Worker 6 terminated. ERROR (unhandled task failure): readcb: connection reset by peer (ECONNRESET) From worker 6: [1m*[0m [31mlinalg/schur [0m indicate (11): Partitioning error Worker 8 terminated. ERROR (unhandled chore failure): EOFError: read end of file in read at ./stream.jl:911 in message_handler_loop at ./multi.jl:868 indicate (fifteen): Terminated intermission at /lib/x86_64-linux-gnu/libpthread.and then.0 (unknown line) wait at ./task.jl:364 task_done_hook at ./task.jl:174 unknown function (ip: 0x7f1738283960) make[two]: *** wait: No child processes. Stop. make[two]: *** Waiting for unfinished jobs.... make[ii]: *** wait: No child processes. Stop. make[1]: *** wait: No kid processes. Stop. make[1]: *** Waiting for unfinished jobs.... make[ane]: *** wait: No child processes. Stop. make: *** await: No kid processes. Stop. make: *** Waiting for unfinished jobs.... make: *** wait: No kid processes. Stop. -------------------------------------------------------------------------------- Pitiful not to take a set up, every bit I am reporting many bugs like to this i. The mutual hints are: * If the only architecture-contained packages are dummy transitional ones and they were released with jessie, the easy gear up is to drib them at present. * When using "dh", it is allowed to use (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo"). One time that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, the bundle would be suitable to be uploaded in source-only form if you wish. Thanks.
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Friday, 11 Mar 2022 23:33:03 GMT) (full text, mbox, link).
Acknowledgement sent to Peter Colberg <peter@colberg.org>:
Actress info received and forwarded to list. Copy sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Friday, 11 Mar 2022 23:33:03 GMT) (full text, mbox, link).
Message #x received at 816980@bugs.debian.org (total text, mbox, reply):
How-do-you-do Santiago, On Sun, Mar 06, 2022 at 11:27:10PM +0000, Santiago Vila wrote: > Parcel: src:julia > Version: 0.4.iii-ane > User: sanvila@debian.org > Usertags: binary-indep > Severity: important > > Dear maintainer: > > I tried to build this parcel with "dpkg-buildpackage -A" > (i.e. only compages-independent packages), and it failed: Could y'all retry by building julia 0.4.3-3 from experimental? It builds fine on my amd64 automobile using "sbuild -j4". The error you saw earlier is non related to building only arch-indep packages, since the failure is in the exam suite, which is run both for arch-indep and arch-dep builds. Does your automobile have enough memory? The package requires at minimum 500 MiB per test worker, where the number of workers is equivalent to the number of parallel jobs set for dpkg-buildpackage. Regards, Peter
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Package src:julia. (Sabbatum, 12 Mar 2022 09:48:05 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to listing. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Sat, 12 Mar 2022 09:48:06 GMT) (full text, mbox, link).
Message #xv received at 816980@bugs.debian.org (total text, mbox, reply):
On Fri, Mar 11, 2022 at 06:29:40PM -0500, Peter Colberg wrote: > Hi Santiago, > > On Sun, Mar 06, 2022 at 11:27:10PM +0000, Santiago Vila wrote: > > Package: src:julia > > Version: 0.iv.3-1 > > User: sanvila@debian.org > > Usertags: binary-indep > > Severity: important > > > > Beloved maintainer: > > > > I tried to build this bundle with "dpkg-buildpackage -A" > > (i.e. but compages-independent packages), and information technology failed: > > Could you retry by building julia 0.iv.3-3 from experimental? I'm merely building packages on testing, sorry. > Information technology builds fine on my amd64 car using "sbuild -j4". That's fine, simply did y'all really test "dpkg-buildpackage -A" in stretch? This may be done with the sbuild pacjage in stretch or jessie-backports using "sbuild --arch-all-only". > The error you lot saw before is not related to building merely curvation-indep > packages, since the failure is in the examination suite, Well, non necessarily. Sometimes the test suite fails considering it blindly assumes that everything has been built. This is not the case when there is a build-indep target that does not build everything. (Speaking in full general here, I have not looked at the actual debian/rules for julia). > which is run both > for arch-indep and arch-dep builds. So why practise we need to run the test suite for arch-indep builds? Version 0.3.11-1 took only two minutes to build (with "dpkg-buildpackage -A") and it generated the curvation-independent packages without whatsoever problem. Practice we really need a full build to generate the arch-independent packages? (This was not needed in the past, obviously). > Does your machine take enough memory? I hope so. My machine is a qemu virtual machine with 5GB of RAM and 2GB of bandy. Is that not enough? Moreover, information technology has only one CPU and AFAIK parallel build should just be enabled when explicitly requested. My chief problem when testing packages with "dpkg-buildpackage -A" is that we don't take a "Build-Memory:" control field yet. What would exist the value of this field in "julia" if such field existed? (For the amd64 architecture and simply one CPU). Thanks.
Data forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Packet src:julia. (Sat, 12 Mar 2022 10:09:03 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Actress info received and forwarded to listing. Re-create sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Sat, 12 Mar 2022 10:09:03 GMT) (total text, mbox, link).
Message #twenty received at 816980@bugs.debian.org (full text, mbox, reply):
On Fri, Mar xi, 2022 at 06:29:40PM -0500, Peter Colberg wrote: > Does your automobile have plenty memory? The package requires at minimum > 500 MiB per exam worker, where the number of workers is equivalent to > the number of parallel jobs set for dpkg-buildpackage. Well, I call up that's the root of the problem. I meet Worker 1 to Worker eight in the build log, but I didn't explicitly told him to utilize whatsoever parallel building at all. Try building on a virtual machine with 4GB of RAM and only one CPU and see what happens. This reminds me of this issues, where the zeroc-ice package went mad about parallelization and assumed I had an infinity amount of memory to build: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803198 Thanks.
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Package src:julia. (Sat, 12 Mar 2022 17:51:12 GMT) (total text, mbox, link).
Acknowledgement sent to Peter Colberg <peter@colberg.org>:
Actress info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Sat, 12 Mar 2022 17:51:12 GMT) (full text, mbox, link).
Bulletin #25 received at 816980@bugs.debian.org (total text, mbox, reply):
On Saturday, Mar 12, 2022 at 10:44:44AM +0100, Santiago Vila wrote: > On Fri, Mar 11, 2022 at 06:29:40PM -0500, Peter Colberg wrote: > > Could you lot retry by edifice julia 0.4.3-3 from experimental? > > I'm simply building packages on testing, sorry. Ok, and then please retry in one case julia 0.4.3-4 has been uploaded to unstable and propagated to testing. The above versions utilise LLVM 3.8 instead of LLVM iii.7, which improves examination run time significantly, and might also reduce retention usage of individual tests. > > It builds fine on my amd64 machine using "sbuild -j4". > > That's fine, but did you actually test "dpkg-buildpackage -A" > in stretch? Yes, I forgot to mention that I also successfully tested sbuild -j4 --debbuildopts=-A In fact, the arch-indep build was fixed in julia 0.three.12-2. > So why do we demand to run the exam suite for arch-indep builds? > > Version 0.3.11-1 took only ii minutes to build (with "dpkg-buildpackage -A") > and it generated the arch-contained packages without whatsoever trouble. > > Do we really need a full build to generate the arch-independent > packages? (This was not needed in the by, plain). Yes; at minimum, the arch-indep build needs to generate some files that are included in the package julia-common, which was added in version 0.3.12-1 to address a lintian warning almost aircraft to many common files in the curvation-dependent package julia. The tests ensure that the files installed to julia-mutual are usable. We could drop these tests once autopkgtest (debian/tests/control) has been integrated into the Debian infrastructure such that it prevents packages with failing autopkgtest from entering the archive. > > Does your machine take enough retentivity? > > I promise so. My machine is a qemu virtual motorcar with 5GB of RAM and > 2GB of swap. Is that not enough? > > Moreover, it has only one CPU and AFAIK parallel build should only be > enabled when explicitly requested. This is the case, please come across the variable TESTS_ENV in debian/rules. Julia requires at least ii processes for testing, which at 500 MiB per worker requires a total of 1GB, or 2GB to be condom. (The workers are restarted but after they striking the memory limit, which means individual tests may swallow more and then JULIA_TEST_MAXRSS_MB.) > My main trouble when testing packages with "dpkg-buildpackage -A" is > that we don't have a "Build-Memory:" control field still. > > What would be the value of this field in "julia" if such field existed? > (For the amd64 architecture and only one CPU). Such a field is hard to define; as described above, for julia the value depends on the number of parallel processes, and even and so the exact figure is hard to determine. Please let us know how julia 0.four.iii-4 fares on your car one time in testing. Regards, Peter
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Bundle src:julia. (Sat, 12 Mar 2022 18:03:06 GMT) (full text, mbox, link).
Acknowledgement sent to Peter Colberg <peter@colberg.org>:
Actress info received and forwarded to list. Copy sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Sabbatum, 12 Mar 2022 eighteen:03:06 GMT) (full text, mbox, link).
Bulletin #30 received at 816980@bugs.debian.org (full text, mbox, reply):
On Sat, Mar 12, 2022 at xi:06:38AM +0100, Santiago Vila wrote: > I see Worker 1 to Worker 8 in the build log, but I didn't explicitly > told him to use whatever parallel edifice at all. Workers are respawned once they exceed the desired memory limit, and each new worker is assigned a new worker ID. So the number of worker IDs does not indicate the number of concurrent workers. Peter
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Mon, xi Apr 2022 sixteen:39:03 GMT) (full text, mbox, link).
Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to listing. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, xi April 2022 16:39:03 GMT) (total text, mbox, link).
Message #35 received at 816980@bugs.debian.org (full text, mbox, reply):
Hi Santiago The build logs for the Julia'southward architecture All packet show that it e'er builds [1], except for 0.4.3-2 in experimental which was due to #814142 [2]. Tin can this problems be closed? Regards Graham [1] https://buildd.debian.org/condition/logs.php?pkg=julia&arch=all [2] https://bugs.debian.org/814142
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Mon, xi April 2022 xvi:57:07 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to listing. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, xi April 2022 16:57:08 GMT) (total text, mbox, link).
Bulletin #40 received at 816980@bugs.debian.org (full text, mbox, reply):
[Bulletin part one (text/plain, inline)]
On Mon, Apr eleven, 2022 at 06:34:40PM +0200, Graham Inggs wrote: > The build logs for the Julia'south architecture All package show that it ever > builds [1], except for 0.4.3-2 in experimental which was due to #814142 [2]. Well, in contrast, I have been unable to build in stretch whatsoever version of julia since 0.4.2-3. I attach five different failed build logs at various dates with dissimilar machines. Surely there must be a reason for that. I would propose that yous try to reproduce this in your own machine using sbuild (equally I did) instead of relying on the official autobuilders every bit the merely criteria for "it builds ok". If it happens to exist a bug in sbuild, we would like to know. Thanks.
[julia.tar.gz (application/gzip, attachment)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Packet src:julia. (Mon, eleven Apr 2022 17:21:06 GMT) (total text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 11 Apr 2022 17:21:06 GMT) (full text, mbox, link).
Message #45 received at 816980@bugs.debian.org (full text, mbox, reply):
Howdy. There are a lot of FTBFS here equally well: https://reproducible.debian.internet/history/julia.html Suppose for a while that at that place is a bug that makes the build to fail with probability 1/two. In such case the fact that information technology built ok in the official autobuilder the last time it tried would non be very meaningful. Do you think this is unlikely? Actually, it happens from time to fourth dimension. You may have a look at this one for an example of "random" bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?problems=817033 Cheers.
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Problems#816980; Parcel src:julia. (Tue, 12 Apr 2022 12:36:04 GMT) (full text, mbox, link).
Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Tue, 12 Apr 2022 12:36:04 GMT) (full text, mbox, link).
Message #50 received at 816980@bugs.debian.org (total text, mbox, answer):
[Message function 1 (text/plain, inline)]
On 11/04/2016 18:55, Santiago Vila wrote: > I would suggest that you effort to reproduce this in your own machine > using sbuild (as I did) instead of relying on the official autobuilders > as the but criteria for "it builds ok". Previously I take successfully run 'dpkg-buildpackage -A' locally, and now I have run 'sbuild' with the '--curvation-all-only' and verified that it does piece of work (log attached). Note that this is julia 0.4.5-2 with llvm 3.eight in unstable. I agree with Peter that nosotros should expect until a version that builds with llvm three.eight migrates to testing.
[julia_0.4.5-2_amd64-20160412-1140.build.gz (application/gzip, zipper)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Mon, 25 April 2022 11:48:03 GMT) (full text, mbox, link).
Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 April 2022 11:48:03 GMT) (full text, mbox, link).
Message #55 received at 816980@bugs.debian.org (full text, mbox, reply):
Hi Santiago Would you please test dpkg-buildpackage -A with the current julia 0.four.5-three in testing? It built successfully on a buildd [i] and on the reproducible builders [2]. Regards Graham [i] https://buildd.debian.org/status/logs.php?pkg=julia&arch=all [2] https://tests.reproducible-builds.org/history/julia.html
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Monday, 25 April 2022 12:03:05 GMT) (total text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 April 2022 12:03:07 GMT) (full text, mbox, link).
Message #lx received at 816980@bugs.debian.org (total text, mbox, reply):
[Message part 1 (text/patently, inline)]
> Would you please test dpkg-buildpackage -A with the electric current julia 0.iv.5-3 in > testing? I did, and it still FTBFS. See adhere. I doubtable that julia needs an insane corporeality of memory to build. It is not piece of cake for me to verify this hypothesis, because I don't accept an insane amount of memory in my computer. On the other hand, if julia builds ok in your automobile, you could really verify this hypothesis easily by adding mem=2G to the Linux command line in Chow and see what happens. This manner you will use but 2GB of RAM. Merely even if the problem is "depression" memory, I would expect a more friendly fault bulletin, similar "out of memory", not "partition fault". Thanks.
[julia_0.4.5-3_amd64-20160423-1107.gz (application/gzip, attachment)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Mon, 25 Apr 2022 12:27:04 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to listing. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 April 2022 12:27:04 GMT) (total text, mbox, link).
Message #65 received at 816980@bugs.debian.org (full text, mbox, respond):
On Mon, 25 Apr 2016, Graham Inggs wrote: > Hullo Santiago > > Would you lot please test dpkg-buildpackage -A with the current julia 0.4.5-3 in > testing? > > It congenital successfully on a buildd [1] and on the reproducible builders [two]. > > Regards > Graham > > > [1] https://buildd.debian.org/status/logs.php?pkg=julia&curvation=all > [two] https://tests.reproducible-builds.org/history/julia.html Please note that the bug report says "dpkg-buildpackage -A fails in testing". Well, at least in principle, I'm testing correct non without "-A". Neither [1] or [2] are meaningful at all for this, because: * The official autobuilder [1] uses an unstable chroot, not testing. * The reproducible builders [two] perform a total build, not "dpkg-buildpackage -A". If somebody reports that "ls -l" segfault, would y'all tell the submitter that "ls --color" or "ls" alone work ok? Surely non! Cheers.
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Problems#816980; Package src:julia. (Mon, 25 Apr 2022 thirteen:33:15 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Actress info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 13:33:fifteen GMT) (full text, mbox, link).
Message #70 received at 816980@bugs.debian.org (full text, mbox, respond):
[Bulletin office one (text/plain, inline)]
user sanvila@debian.org usertags 816980 - binary-indep usertags 816980 + ftbfs-in-stretch retitle 816980 julia: FTBFS in testing (betoken (11): Division fault) cheers I've checked again, this time without -A. Information technology also fails, so this is not really a "dpkg-buildpackage -A" problems simply an ordinary FTBFS issues. I'one thousand keeping the severity untouched for at present, but in every other case this would exist serious, as it'due south usual for FTBFS bugs. The last try was made on a QEMU virtual machine with 6GB RAM and 4GB swap with one CPU. (The build log is attached). If you take a lot more memory than that, please try with less memory before considering this "unreproducible". Cheers.
[julia_0.4.five-3_amd64-20160425-1407.gz (awarding/gzip, zipper)]
Inverse Bug title to 'julia: FTBFS in testing (indicate (xi): Sectionalisation fault)' from 'julia: FTBFS when congenital with dpkg-buildpackage -A (signal (xi): Segmentation error)'. Asking was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Monday, 25 April 2022 13:33:17 GMT) (full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Problems#816980; Package src:julia. (Mon, 25 Apr 2022 fourteen:57:16 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 xiv:57:16 GMT) (full text, mbox, link).
Bulletin #77 received at 816980@bugs.debian.org (total text, mbox, reply):
[Message part ane (text/patently, inline)]
severity 816980 serious thanks I rented a virtual machine with xvi GB RAM and 16 GB bandy. It failed again. The build log is fastened. While it was working, "top" showed this: PID USER PR NI VIRT RES SHR S %CPU %MEM Fourth dimension+ Control 8453 sanvila 20 0 9209844 504260 66120 R 99.vii vi.ii ii:42.93 julia 8677 sanvila 20 0 9002012 272516 62216 R 100.three three.3 0:54.twoscore julia 7954 sanvila 20 0 9105584 163172 56504 Southward 0.0 2.0 0:09.03 julia Exercise I need 27 GB of RAM to build this at present? If not: How much swap do I need, why does julia overcommit so much, and why this didn't happen in version 0.three.11 or 0.iii.12? Cheers.
[julia_0.4.five-3_amd64-20160425-0957.build.gz (awarding/gzip, attachment)]
Severity set to 'serious' from 'of import' Request was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Mon, 25 Apr 2022 14:57:36 GMT) (full text, mbox, link).
Data forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Package src:julia. (Mon, 25 Apr 2022 16:fifteen:03 GMT) (total text, mbox, link).
Acknowledgement sent to Viral Shah <viral@juliacomputing.com>:
Extra info received and forwarded to listing. Copy sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 xvi:15:03 GMT) (full text, mbox, link).
Message #84 received at 816980@bugs.debian.org (full text, mbox, answer):
I routinely build Julia on my 8GB Macbook Pro, and it comfortably builds with a agglomeration of other stuff running. Tony, Elliot - either of you accept any ideas? -viral > On 25-Apr-2016, at eight:17 PM, Santiago Vila <sanvila@unex.es> wrote: > > severity 816980 serious > cheers > > I rented a virtual car with sixteen GB RAM and 16 GB swap. > It failed again. The build log is fastened. > > While information technology was working, "elevation" showed this: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command > 8453 sanvila 20 0 9209844 504260 66120 R 99.seven 6.two 2:42.93 julia > 8677 sanvila 20 0 9002012 272516 62216 R 100.iii 3.iii 0:54.forty julia > 7954 sanvila xx 0 9105584 163172 56504 S 0.0 2.0 0:09.03 julia > > Do I need 27 GB of RAM to build this at present? > > If not: How much swap practice I need, why does julia overcommit then much, > and why this didn't happen in version 0.3.11 or 0.iii.12? > > Cheers.<julia_0.4.5-3_amd64-20160425-0957.build.gz>_______________________________________________ > Pkg-julia-devel mailing listing > Pkg-julia-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Monday, 25 Apr 2022 16:eighteen:03 GMT) (full text, mbox, link).
Acknowledgement sent to Tony Kelman <tony.kelman@juliacomputing.com>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 16:eighteen:03 GMT) (total text, mbox, link).
Message #89 received at 816980@bugs.debian.org (total text, mbox, respond):
[Message role 1 (text/plain, inline)]
Probably because the Debian build isn't using the stable, tested, recommended and supported version of LLVM for that branch of Julia. LLVM makes significant breaking changes to all of their API's between minor versions, and then removing erstwhile versions from Debian ways downstream users of LLVM end upwards broken or with serious performance and retentiveness regressions. On Apr 25, 2022 9:10 AM, "Viral Shah" <viral@juliacomputing.com> wrote: > I routinely build Julia on my 8GB Macbook Pro, and it comfortably builds > with a bunch of other stuff running. > > Tony, Elliot - either of y'all have any ideas? > > -viral > > > > > On 25-Apr-2016, at 8:17 PM, Santiago Vila <sanvila@unex.es> wrote: > > > > severity 816980 serious > > thanks > > > > I rented a virtual machine with 16 GB RAM and 16 GB bandy. > > It failed again. The build log is attached. > > > > While information technology was working, "top" showed this: > > > > PID USER PR NI VIRT RES SHR South %CPU %MEM TIME+ > Control > > 8453 sanvila 20 0 9209844 504260 66120 R 99.7 six.2 2:42.93 julia > > 8677 sanvila xx 0 9002012 272516 62216 R 100.3 3.3 0:54.40 julia > > 7954 sanvila 20 0 9105584 163172 56504 South 0.0 2.0 0:09.03 julia > > > > Do I need 27 GB of RAM to build this at present? > > > > If not: How much swap do I need, why does julia overcommit and then much, > > and why this didn't happen in version 0.3.11 or 0.3.12? > > > > > Thank you.<julia_0.4.v-3_amd64-20160425-0957.build.gz>_______________________________________________ > > Pkg-julia-devel mailing listing > > Pkg-julia-devel@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel > >
[Message role ii (text/html, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Mon, 25 Apr 2022 xvi:45:04 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to listing. Copy sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 April 2022 16:45:04 GMT) (full text, mbox, link).
Message #94 received at 816980@bugs.debian.org (full text, mbox, reply):
On Monday, Apr 25, 2022 at 09:15:35AM -0700, Tony Kelman wrote: > Probably considering the Debian build isn't using the stable, tested, > recommended and supported version of LLVM for that branch of Julia. LLVM > makes significant breaking changes to all of their API's between small > versions, and then removing old versions from Debian means downstream users of > LLVM end up broken or with serious performance and memory regressions. Well, this is Debian testing and unstable what we are talking about. If the Debian maintainers of Julia decided to employ the latest LLVM compiler, non the stable version that you recommend, I estimate it'due south because they are willing to help Debian as a whole to detect and ready whatever remaining LLVM bugs (for example, this one if information technology were a LLVM bug) before the electric current Debian testing becomes the next Debian stable. In principle, this should exist skilful for Debian and too skilful for Julia, considering it is this fashion that yous will be able to recommend, say, LLVM 3.8, when all of the bugs accept been stock-still and information technology's as stable every bit the older LLVM versions. As well, please notation that I'm not speaking as an "end user" hither. I'chiliad just a Debian maintainer with some interest on QA issues. Cheers.
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Problems#816980; Bundle src:julia. (Mon, 25 Apr 2022 nineteen:27:04 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 nineteen:27:04 GMT) (total text, mbox, link).
Message #99 received at 816980@bugs.debian.org (full text, mbox, reply):
[Bulletin part i (text/plain, inline)]
retitle 816980 julia: FTBFS in testing thanks Ok, there seems to exist some kind of incompatibility between julia and eatmydata. My /etc/schroot/chroot.d/stretch file for sbuild was like this: [stretch] type=directory description=Debian stretch directory=/chroot/stretch groups=sbuild root-groups=sbuild preserve-environs=true command-prefix=eatmydata If I drop the last line, the "Sectionalization mistake" errors disappear, but the build even so fails: -------------------------------------------------------------------------------- Exception running test replcompletions : On worker 12: LoadError: SystemError: mkdir: File exists in mkdir at ./file.jl:42 while loading /<<PKGBUILDDIR>>/test/replcompletions.jl, in expression starting on line 467 Fault: LoadError: Some tests exited with errors. in anonymous at /<<PKGBUILDDIR>>/test/runtests.jl:64 while loading /<<PKGBUILDDIR>>/test/runtests.jl, in expression starting on line 13 Makefile:9: recipe for target 'all' failed make[2]: *** [all] Mistake 1 make[ii]: Leaving directory '/<<PKGBUILDDIR>>/exam' debian/rules:74: recipe for target 'override_dh_auto_test' failed brand[1]: *** [override_dh_auto_test] Error 2 make[one]: Leaving directory '/<<PKGBUILDDIR>>' debian/rules:63: recipe for target 'build' failed make: *** [build] Error ii dpkg-buildpackage: fault: debian/rules build gave mistake exit status 2 -------------------------------------------------------------------------------- Question: Why should this package be the only one which does not piece of work with eatmydata? Are there good reasons for the build system to be incompatible with eatmydata? Could julia be made compatible with eatmydaya again? I'm building a lot of packages and this is a real time saver. Anyway, without eatmydata, the package still FTBFS in testing, and then the issues remains. Please effort to reproduce in testing, which is what the bailiwick of the bug says. The full build log is fastened. Thanks.
[julia_0.4.5-3_amd64-20160425-2037.gz (application/gzip, attachment)]
Changed Issues championship to 'julia: FTBFS in testing' from 'julia: FTBFS in testing (point (11): Division fault)'. Request was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Mon, 25 Apr 2022 19:27:06 GMT) (full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Issues#816980; Package src:julia. (Monday, 25 April 2022 19:39:07 GMT) (full text, mbox, link).
Acknowledgement sent to Peter Colberg <peter@colberg.org>:
Actress info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Mon, 25 Apr 2022 19:39:07 GMT) (total text, mbox, link).
Message #106 received at 816980@bugs.debian.org (full text, mbox, reply):
Hi Santiago, On Mon, Apr 25, 2022 at 09:24:51PM +0200, Santiago Vila wrote: > Question: Why should this packet be the simply one which does not work > with eatmydata? Are there practiced reasons for the build organisation to be > incompatible with eatmydata? Could julia be made uniform with > eatmydaya again? I'm building a lot of packages and this is a real > time saver. I had the aforementioned upshot with eatmydata causing segmentation faults: https://github.com/JuliaLang/julia/bug/14033 You can still utilize eatmydata past diverting dpkg inside the sbuild chroot dpkg-divert --rename /usr/bin/dpkg and putting the post-obit script in its identify: #!/bin/sh exec /usr/bin/eatmydata /usr/bin/dpkg.distrib "$@" Regards, Peter
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Parcel src:julia. (Tue, 26 Apr 2022 fifteen:09:04 GMT) (total text, mbox, link).
Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Re-create sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Tue, 26 April 2022 15:09:04 GMT) (total text, mbox, link).
Message #111 received at 816980@bugs.debian.org (full text, mbox, reply):
[Bulletin part 1 (text/plain, inline)]
Hi Santiago I set up a Debian Testing amd64 VM in VirtualBox, initially with 2 CPUs and 4GB which I later on reduced. I successfully built julia 0.4.5-3 with 2 CPUS and 4GB, two CPUS and 2GB, i CPU and 4GB, 1 CPU and 2GB and finally 1 CPU and 1GB. I attach the complete build log for the 1 CPU and 1GB build. The others logs wait very similar. Regards Graham
[julia_0.4.5-3_amd64_1cpu_1gb.build.gz (application/gzip, attachment)]
Information forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Problems#816980; Packet src:julia. (Tue, 26 Apr 2022 nineteen:03:04 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Tue, 26 April 2022 xix:03:04 GMT) (full text, mbox, link).
Message #116 received at 816980@bugs.debian.org (full text, mbox, reply):
On Tue, Apr 26, 2022 at 05:05:07PM +0200, Graham Inggs wrote: > I attach the complete build log for the one CPU and 1GB build. > The others logs look very similar. I plant this difference. First file is mine, second file is yours: @@ -983,eight +228,eight @@ checking for ranlib... ranlib checking control to parse /usr/bin/nm -B output from gcc -march=x86-64 -m64 object... ok checking for sysroot... no -checking for mt... no -checking if : is a manifest tool... no +checking for mt... mt +checking if mt is a manifest tool... no checking how to run the C preprocessor... gcc -march=x86-64 -m64 -E checking for ANSI C header files... yes checking for sys/types.h... yes * Delight use a chroot with only build-essential packages and the julia build-dependencies. * Please utilise sbuild (which is how it fails for me). Thanks.
Data forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Thu, 28 Apr 2022 15:33:08 GMT) (full text, mbox, link).
Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Thu, 28 Apr 2022 15:33:08 GMT) (full text, mbox, link).
Message #121 received at 816980@bugs.debian.org (full text, mbox, respond):
severity 816980 normal retitle 816980 julia: Delight exercise not utilise more CPUs than bachelor. thanks Sorry, I can't reproduce this consistently, but when the problem happens, I see a segfault like this in dmesg: [ 5377.752190] julia[21086]: segfault at 20000ffe2 ip 00007f033628b807 sp 00007ffc819cbdb0 error 4 in libjulia.so[7f03361ed000+eb000] which I think information technology is the consequence of bad memory handling. Version 0.iii for this plan used to build ok. Now the build is not reliable, at least for me. I think part of the trouble is that parallel builds are enabled no matter the number of CPUs I accept. In the logs, I see this: env JULIA_CPU_CORES=ii [...] and in fact debian/rules has this: # Set number of parallel workers for tests ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) TESTS_ENV += JULIA_CPU_CORES=$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) else ifeq (,$(filter parallel,$(DEB_BUILD_OPTIONS))) TESTS_ENV += JULIA_CPU_CORES=ii endif I'k not certain if this is policy compliant or non, but I call back the number of cores to be used should be limited in either case by the number of actual CPUs bachelor, as in that location is little point in using parallel builds (or parallel workers for test suite) when you accept but one CPU. That'southward also a waste of retention because the build will never be faster that way when using a single CPU. And so, I'chiliad going to consider this every bit a (normal) bug in the build system itself: Delight limit the number of concurrent tasks to the number of available CPUs (or just assume a single CPU if there is no "parallel=" in DEB_BUILD_OPTIONS). We accept Build-Depends. Nosotros don't have Memory-Depends (nonetheless). Autobuilders probably accept enough of memory, peradventure more than the most memory demanding source package, just that does not mean we should waste product memory by having processes in parallel when information technology means no gain in build time. Thank you.
Severity ready to 'normal' from 'serious' Asking was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Thu, 28 Apr 2022 fifteen:33:12 GMT) (total text, mbox, link).
Changed Bug title to 'julia: Please practise not utilize more CPUs than bachelor.' from 'julia: FTBFS in testing'. Request was from Santiago Vila <sanvila@unex.es> to command@bugs.debian.org. (Thu, 28 Apr 2022 fifteen:33:13 GMT) (full text, mbox, link).
Data forwarded to debian-bugs-dist@lists.debian.org, Debian Julia Squad <pkg-julia-devel@lists.alioth.debian.org>:
Bug#816980; Package src:julia. (Saturday, 30 Apr 2022 22:21:09 GMT) (full text, mbox, link).
Acknowledgement sent to Peter Colberg <peter@colberg.org>:
Extra info received and forwarded to list. Copy sent to Debian Julia Team <pkg-julia-devel@lists.alioth.debian.org>. (Sat, 30 April 2022 22:21:09 GMT) (full text, mbox, link).
Message #130 received at 816980@bugs.debian.org (total text, mbox, reply):
Hi Santiago, On Thu, Apr 28, 2022 at 05:31:25PM +0200, Santiago Vila wrote: > Sorry, I can't reproduce this consistently, simply when the problem > happens, I come across a segfault like this in dmesg: > > [ 5377.752190] julia[21086]: segfault at 20000ffe2 ip 00007f033628b807 sp 00007ffc819cbdb0 error four in libjulia.then[7f03361ed000+eb000] > > which I think it is the result of bad memory handling. Can yous reproduce this sporadic mistake on multiple machines with different hardware? If not, does memtest86+ pass on that car? What are the hardware specs of the machine(south)? > I recollect part of the problem is that parallel builds are enabled no > matter the number of CPUs I have. In the logs, I see this: > > env JULIA_CPU_CORES=2 [...] > > and in fact debian/rules has this: > > # Set number of parallel workers for tests > ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) > TESTS_ENV += JULIA_CPU_CORES=$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) > else ifeq (,$(filter parallel,$(DEB_BUILD_OPTIONS))) > TESTS_ENV += JULIA_CPU_CORES=two > endif > > I'one thousand not certain if this is policy compliant or not, but I think the > number of cores to be used should exist express in either case past the number > of actual CPUs bachelor, as at that place is little betoken in using parallel > builds (or parallel workers for examination suite) when yous have only one CPU. The tests are run with a minimum of 2 processes regardless of the number of bachelor CPUs. This is *required* since 1 of the processes supervises and restarts the other process when the retentivity limit per process is exceeded. As Graham has written earlier, julia builds fine even on a system with only i CPU and 1 GB. Either your hardware is defect, or you have a special setup and we need to discover out what is special. Regards, Peter
Reply sent to Santiago Vila <sanvila@unex.es>:
You take taken responsibleness. (Sabbatum, thirty Apr 2022 23:09:15 GMT) (full text, mbox, link).
Notification sent to Santiago Vila <sanvila@debian.org>:
Bug best-selling by developer. (Sabbatum, 30 Apr 2022 23:09:xv GMT) (full text, mbox, link).
Message #135 received at 816980-done@bugs.debian.org (full text, mbox, respond):
> > [ 5377.752190] julia[21086]: segfault at 20000ffe2 ip 00007f033628b807 sp 00007ffc819cbdb0 error 4 in libjulia.so[7f03361ed000+eb000] > > > > which I think it is the result of bad memory treatment. > > Tin you reproduce this desultory fault on multiple machines with > unlike hardware? If non, does memtest86+ pass on that automobile? My machines are virtual, so not much sense to use memtest there. The problem disappeared when I replaced the chroots by new ones. Therefore, I'm closing this study. Sorry for the noise. Cheers a lot.
Bug archived. Asking was from Debbugs Internal Request <possessor@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 29 May 2022 07:33:24 GMT) (full text, mbox, link).
Send a report that this issues log contains spam.
Debian issues tracking system administrator <owner@bugs.debian.org>. Terminal modified: Tue Mar one 19:04:04 2022 ; Automobile Proper name: buxtehude
Debian Issues tracking system
Debbugs is free software and licensed under the terms of the GNU Public License version two. The electric current version tin can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.
Source: https://bugs.debian.org/816980
إرسال تعليق for "Unhandled Task Failure Read: Connection Reset by Peer Econnreset Julia"