Bug#919628: Apply Julia's LLVM patches
Hi, On Fri, 18 Jan 2019 at 10:31, Sylvestre Ledru wrote: > > Please check and apply Julia's LLVM patches to Debian's LLVM 6.0.1: > > > > https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L390-L432 > > https://github.com/JuliaLang/julia/tree/master/deps/patches > > > > I don't quite understand what these patches are doing. > > Would be nice to have a better understanding of why they have been added. > > Performances, bug, stability, etc. Upstream's note about these patches: https://github.com/julialang/julia#llvm These patches relate to performance and bugs according to the above note. > Besides the arm issue, what otherwise is blocking you with the current > llvm-toolchain-6 ? Nothing else. I have no reason to keep an embedded llvm if (1) the arm problem and (2) the upstream patches have been dealt with. > Do you know if there is a documentation somewhere? I think the best documentation about these patches are git commit messages following git blame. For example https://github.com/JuliaLang/julia/commit/e99204b52be23c49b5185d270b6697b097b16513 refers to a bug: https://github.com/JuliaLang/julia/issues/28726 I'm glad to assemble a detailed list of patches and their corresponding bugs if you ask. And note that I'm traveling tomorrow (Jan 20) so please don't expect response from me on that day. > > So in order to > > use upstream's LLVM patches, the most straightforward way is to > > ship an embedded LLVM in Julia's source package. > > Sure but it doesn't scale and this is against the Debian policy (cf 4.13). Indeed, and embedding an LLVM makes the package much much harder to build. > We have already too many versions of llvm in the archive, no need to add > one more (esp > as I am active on llvm-toolchain-*) Although patching LLVM for julia requires some time, the resulting Debian package could do very well with Julia 1.0.X (upstream's long time support branch, currently in unstable, planned for Buster), and Julia 1.X (non-LTS branch. Not decided whether to upload)
Bug#919626: Emits NEON code on armv7a due to wrong CPU detection
Glad to hear, thanks! On Fri, 18 Jan 2019 at 09:49, Sylvestre Ledru wrote: > > I fixed that in 7, I can probably easily backport the fix to 6. > > S > > > Le 18/01/2019 à 04:41, M. Zhou a écrit : > > Package: llvm-6.0-dev > > Version: 1:6.0.1-9.2 > > X-Debbugs-CC: gin...@debian.org > > > > Dear LLVM maintainers, > > > > Recently Julia FTBFS on armhf due to SIGILL from NEON instruction. > > (ginggs digged into the SIGILL and confirmed it's due to NEON) > > However, julia is supposed to compile multiple code branches where > > one of them involves no NEON instruction. Emulation based on QEMU's > > cortex-a7 CPU proves this point. > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919183 > > > > Neither Debian's LLVM, nor Julia's patched LLVM, has fixed this issue. > > > > The incorrect CPU detection can be reproduced on abel, LLVM > > also emits NEON code to abel's CPU. > > > > ___ > > Pkg-llvm-team mailing list > > pkg-llvm-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team -- Best,
Bug#911937: FTBFS on architecture=all
Package: zfsutils-linux
Version: 0.7.11-2
Severity: serious
Owner: !
https://buildd.debian.org/status/package.php?p=zfs-linux
dh_python3 -i -O--parallel
E: dh_python3 dh_python3:176: no package to act on (python3-foo or one with
${python3:Depends} in Depends)
dh_systemd_enable -i -O--parallel
debian/rules override_dh_installinit
make[1]: Entering directory '/<>'
dh_installinit -r --no-start --name zfs-import
dh_installinit -r --no-start --name zfs-mount
dh_installinit -r --no-start --name zfs-share
dh_installinit -R --no-start --name zfs-zed
ln -sr /dev/null \
debian/zfsutils-linux/lib/systemd/system/zfs-import.service
ln: failed to create symbolic link
'debian/zfsutils-linux/lib/systemd/system/zfs-import.service': No such file or
directory
make[1]: *** [debian/rules:161: override_dh_installinit] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:35: binary-indep] Error 2
Bug#826994: ZFS Missing init-scripts, Status? #826994
Hi Chris, Could you please help me review the pending -2 upload? It's hard to go through the historical discussion. It's possible that I missed something. https://salsa.debian.org/zfsonlinux-team/zfs/tree/lumin I tested this branch with my Debian Unstable (OpenRC) setup. Is there any patch that should go into -2 as well? On Thu, Oct 25, 2018 at 07:06:25AM -0600, Chris Dos wrote: > On 10/25/18 6:16 AM, Lumin wrote: > > Hi Chris, > > > > I guess aron is busy recently. Anyway personally I'm going to look into > > non-systemd init system support for ZFS because I planned to get rid of > > systemd forever. > > > > Since I'm new to this package and it's bugs, some time is needed for me > > to go through the historical discussions and do some checks and tests > > by myself. That will take some time. > > Good news. Please let me know if I can help in anyway. > > Chris
Bug#826994: ZFS Missing init-scripts, Status? #826994
Hi Chris, I guess aron is busy recently. Anyway personally I'm going to look into non-systemd init system support for ZFS because I planned to get rid of systemd forever. Since I'm new to this package and it's bugs, some time is needed for me to go through the historical discussions and do some checks and tests by myself. That will take some time. On Wed, Oct 24, 2018 at 09:52:01AM -0600, Chris Dos wrote: > Hello Aron, > > I would just like to get a final statement from you regarding if this patch is > going to be applied or not? > > If this sysvinit bug is going to forever remain a wishlist and never have the > patch applied, then say so and I'll make other arrangements and no longer > maintain the patch. > > Chris
Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code
Some updates about this pre-RFS: Summary: 1. The README.Debian file is totally invalidated. Please don't review the repo. 2. I switched to use python plus ninja for building Debian's TF, which may have a chance to evolve into the final solution. On Fri, Aug 24, 2018 at 22:58 Lumin wrote: > > 2. any help will be appreciated, especially for CMake. > Well, currently the packaging repo is totally a mess since there are 4 sets of build systems. Don't review the repo before I remove three of them, because no one except for myself can understand what's happening there. Bazel, the native build system for TF, is impossible to enter Debian release. Initially I forked upstream's contributed cmake build because cmake can build a complete libtensorflow.so and pywrap_tensorflow_internal. However this set of makefile is too much complicated to read and maintain. For simplicity I forked upstream's contributed makefile build. It only compile a core set of functionality. However, it's not able to build python wrapper. To extend the makefile build I wrote another set of makefile from scratch, imitating the original makefile build. Finally I find it obsecure to understand what happend when something goes wrong. Eventually I started to write yet another build system with python plus ninja-build with the experience obtained from the previous attempts. I think there won't be the fifth build system since python plus ninja just works like what I want. As a result, the whole todo list written in debian directory was invalidated by such frequent change in build system. Please don't review any file in the packaging repo. The python plus ninja build system can produce libtensorflow_framework.so now. > Details > --- > > This not a real RFS, but sort of weak request for review/help. > I'm not proficient in CMake so I'm not sure whether I'm doing > the correct choice all the time. Anyway, The good news is that > I'm already able to build libtensorflow.so for Debian experimental, > on both amd64 and ppc64el architectures. > > At the time of writing, debomatic-amd64 has nearly finished the build > but failed (maybe not enough memory): > > http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.0+dfsg-A1/buildlog > Note, this buildlog is as big as 107MB. > > > Here is a list of remaining TODOs for stage A: > --- > (The list is copied from README.Debian at > https://salsa.debian.org/science-team/tensorflow , > please lookup README.Debian for the full version) > > > - [x] prevent the build system from downloading anything. > - [x] deal with all the C/C++ lib dependencies. > - [x] produce libtensorflow.so.1.10 and install it into .deb package. > - [x] ambiguous FFT2D license. > > - [ ] build tests files (googletest) and run the tests. > - [ ] make sure nothing from contrib is built. they are not officially > supported. > - [ ] remove useless parts from cmake build. > - [ ] misc improvements to cmake build. (at least make it easier to read) > - [ ] is the resulting libtensorflow.so.1.10 correct and working? > - [ ] write autopkgtest with some mini C/C++ programs. > - [ ] working on amd64? > - [ ] working on ppc64el? > - [ ] make sure libtensorflow/amd64 is linked against libmkldnn > - [ ] sort out this confusing lintian E > source-is-missing tensorflow/compiler/aot/codegen_test_o.golden > - [ ] remaining lintian warnings and errors. > - [ ] traverse the 16000+ files in the source tree and complete > d/copyright. > umm. > - [ ] Can't the blob be even smaller? > -rwxr-xr-x 1 debian debian 3.6G Aug 24 13:53 libtensorflow.so.1.10.0 > (unstripped) > -rwxr-xr-x 1 debian debian 104M Aug 24 14:00 libtensorflow.so.1.10.0 > (stripped) > - [ ] 16GB RAM + 16GB swap is not enough to avoid triggering OOM killer? > - [ ] get rid of static linking written for stupid windows > /usr/bin/ld: error: benchmark_model(.debug_info) is too large > (0x35a9f359 bytes) > /usr/bin/ld: error: benchmark_model(.debug_str) is too large > (0x6a545d15 bytes) > /usr/bin/ld: error: benchmark_model(.debug_loc) is too large > (0x1f5b1950 bytes) > make[3]: Leaving directory > '/<>/tensorflow-1.10.0+dfsg/obj-x86_64-linux-gnu' > [ 98%] Built target benchmark_model > /usr/bin/ld: error: compare_graphs(.debug_info) is too large > (0x366f36be bytes) > /usr/bin/ld: error: compare_graphs(.debug_str) is too large > (0x6a64010e bytes) > /usr/bin/ld: error: compare_graphs(.debug_loc) is too large > (0x1fd19fe0 bytes) > - [ ] how to prevent "make install" from building everything again? > &g
Bug#783307: ITP: fzf -- General-purpose command-line fuzzy finder
control: owner ! the two original ITP submitters are either missing, or not interested in fzf anymore. I'm taking over this ITP and this is not any kind of ITP hijack. -- Best,
Bug#907389: ITP: pscircle -- visualizing Linux processes in a form of radial tree
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pscircle Version : 1.2.2 Upstream Author : Ruslan Kuchumov * URL : https://gitlab.com/mildlyparallel/pscircle.git * License : GPL-2 Programming Lang: C Description : visualizing Linux processes in a form of radial tree If output is not specified, pscircle will print the resulting image to X11 root window.
Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org Control: tags -1 +moreinfo Control: blocks -1 by 906646 894411 Control: blocks 804612 by -1 Hi Mentors and d-Science Team, **Many thanks** to Aron Xu for his sponsorship with a 512GB-RAM builder. Without this machine I'll never be able to reach this step, so that postpone this ITP forever. key points of this mail in case if you don't want to read the whole mail 1. able to produce libtensorflow.so now, in a Policy-friendly manner. 2. any help will be appreciated, especially for CMake. Details --- This not a real RFS, but sort of weak request for review/help. I'm not proficient in CMake so I'm not sure whether I'm doing the correct choice all the time. Anyway, The good news is that I'm already able to build libtensorflow.so for Debian experimental, on both amd64 and ppc64el architectures. At the time of writing, debomatic-amd64 has nearly finished the build but failed (maybe not enough memory): http://debomatic-amd64.debian.net/distribution#experimental/tensorflow/1.10.0+dfsg-A1/buildlog Note, this buildlog is as big as 107MB. Here is a list of remaining TODOs for stage A: --- (The list is copied from README.Debian at https://salsa.debian.org/science-team/tensorflow , please lookup README.Debian for the full version) - [x] prevent the build system from downloading anything. - [x] deal with all the C/C++ lib dependencies. - [x] produce libtensorflow.so.1.10 and install it into .deb package. - [x] ambiguous FFT2D license. - [ ] build tests files (googletest) and run the tests. - [ ] make sure nothing from contrib is built. they are not officially supported. - [ ] remove useless parts from cmake build. - [ ] misc improvements to cmake build. (at least make it easier to read) - [ ] is the resulting libtensorflow.so.1.10 correct and working? - [ ] write autopkgtest with some mini C/C++ programs. - [ ] working on amd64? - [ ] working on ppc64el? - [ ] make sure libtensorflow/amd64 is linked against libmkldnn - [ ] sort out this confusing lintian E source-is-missing tensorflow/compiler/aot/codegen_test_o.golden - [ ] remaining lintian warnings and errors. - [ ] traverse the 16000+ files in the source tree and complete d/copyright. umm. - [ ] Can't the blob be even smaller? -rwxr-xr-x 1 debian debian 3.6G Aug 24 13:53 libtensorflow.so.1.10.0 (unstripped) -rwxr-xr-x 1 debian debian 104M Aug 24 14:00 libtensorflow.so.1.10.0 (stripped) - [ ] 16GB RAM + 16GB swap is not enough to avoid triggering OOM killer? - [ ] get rid of static linking written for stupid windows /usr/bin/ld: error: benchmark_model(.debug_info) is too large (0x35a9f359 bytes) /usr/bin/ld: error: benchmark_model(.debug_str) is too large (0x6a545d15 bytes) /usr/bin/ld: error: benchmark_model(.debug_loc) is too large (0x1f5b1950 bytes) make[3]: Leaving directory '/<>/tensorflow-1.10.0+dfsg/obj-x86_64-linux-gnu' [ 98%] Built target benchmark_model /usr/bin/ld: error: compare_graphs(.debug_info) is too large (0x366f36be bytes) /usr/bin/ld: error: compare_graphs(.debug_str) is too large (0x6a64010e bytes) /usr/bin/ld: error: compare_graphs(.debug_loc) is too large (0x1fd19fe0 bytes) - [ ] how to prevent "make install" from building everything again? - [ ] upload to experimental. --- Changes: tensorflow (1.10.0+dfsg-A1) UNRELEASED; urgency=medium * Initial release. (Closes: #804612) * Stage A (with Debian revision "A*") indicates that the source package only produce C and C++ library and development files.
Bug#906646: Acknowledgement (RFS: double-conversion/3.0.0+git20180802.4e8b3b5-1 [ITA, tensorflow deps])
Hi mentors, I've tested building all double-conversion's reverse dependencies including libqt5core5a in unstable, none of them was broken. Test platform is ppc64el instead of amd64.
Bug#907050: julia should suggest vim-julia
Package: julia Version: 1.0.0-1 Severity: minor so that I won't forget to do it.
Bug#907021: RFS: sleef/3.3.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sleef" * Package name: sleef Version : 3.3.1-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : math It builds those binary packages: libsleef-dev - SLEEF Vectorized Math Library (development) libsleef3 - SLEEF Vectorized Math Library (libraries) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sleef Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sleef/sleef_3.3.1-1.dsc More information about hello can be obtained from https://www.example.com. https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages Builds [FULLYBUILT] amd64 [BUILDING] arm64 [FULLYBUILT] armhf [FULLYBUILT] i386 [FULLYBUILT] ppc64el [FULLYBUILT] s390x Changes since the last upload: sleef (3.3.1-1) experimental; urgency=medium * New upstream version 3.3.1 * Add symbols lists for: arm64, armhf, ppc64el, s390x, mips, mips64el, mipsel, alpha, hppa, ia64, powerpc, ppc64, powerpcspe, riscv64, sh4, and sparc64. Symbol lists are deduplicated with symlinks.
Bug#907018: RFS: hepmc/2.06.09-3 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "hepmc" * Package name: hepmc Version : 2.06.09-3 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: hepmc-examples - Event Record for Monte Carlo Generators - example files hepmc-reference-manual - Event Record for Monte Carlo Generators - reference manual hepmc-user-manual - Event Record for Monte Carlo Generators - user manual libhepmc-dev - Event Record for Monte Carlo Generators - development files libhepmc4 - Event Record for Monte Carlo Generators libhepmcfio-dev - Monte Carlo event record FIO library - development files libhepmcfio4 - Monte Carlo event record FIO library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/hepmc Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/hepmc/hepmc_2.06.09-3.dsc More information about hello can be obtained from https://www.example.com. https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages Builds [FULLYBUILT] amd64 [FULLYBUILT] arm64 [FULLYBUILT] armhf [FULLYBUILT] i386 [FULLYBUILT] ppc64el [FULLYBUILT] s390x Changes since the last upload: hepmc (2.06.09-3) unstable; urgency=medium * Team Upload. * Cherry-pick from upstream-git: enlarge tolerance of floating point error. Thanks to Adrian Bunk. (Closes: #906708) (https://gcc.gnu.org/PR87036) * Update Homepage to http://hepmc.web.cern.ch/hepmc/ (Closes: #906709) * Update package descriptions. (Closes: #688671) * Bump Standards-Version to 4.2.0 .
Bug#907012: RFS: highwayhash/0~20180209-g14dedec-6
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "highwayhash" * Package name: highwayhash Version : 0~20180209-g14dedec-6 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash (development) libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/highwayhash Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-6.dsc More information about hello can be obtained from https://www.example.com. http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-6/buildlog Changes since the last upload: highwayhash (0~20180209-g14dedec-6) unstable; urgency=medium * Collect symbols update from buildd. (Closes: #897767) + Update symbols for arm64, ppc64el, x32 . * Bump Standards-Version to 4.2.0 (no change).
Bug#906932: kmer FTBFS in clean unstable chroot
Yes, I'm doing parallel build with -j4 On Wed, Aug 22, 2018 at 23:34 Adrian Bunk wrote: > On Wed, Aug 22, 2018 at 01:58:15PM +0000, Lumin wrote: > > Package: kmer > > Version: 0~20150903+r2013-4 > > Severity: serious > > Justification: FTBFS in clean chroot > > > > I cannot build kmer under both Debian experimental, > > and the debian unstable docker. > > > > ``` >^ > > In file included from atac-driver/alignOverlap/overlap.H:45, > > from atac-driver/alignOverlap/overlap-sort.C:19: > > atac-driver/alignOverlap/overlap-stats.H:64:29: warning: invalid suffix > on literal; C++11 requires a space between literal and string macro > [-Wliteral-suffix] > >fprintf(out, uint32FMT" "uint32FMT"\n", i, hist[i]); > > ^ > > ln -f > /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C > /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process1.C > > ln -f > /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C > /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process2.C > > make[2]: *** No rule to make target > '/root/kmer-0~20150903+r2013/atac-driver/libatac/libatac.a', needed by > 'atac-driver/alignOverlap/overlap'. Stop. > > make[2]: *** Waiting for unfinished jobs > > make[2]: Leaving directory '/root/kmer-0~20150903+r2013' > > make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2 > > make[1]: Leaving directory '/root/kmer-0~20150903+r2013' > > make: *** [debian/rules:21: build] Error 2 > > dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > > ``` > > Are you using something like "dpkg-buildpackage -j" or "sbuild -j"? > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > > -- Best,
Bug#906932: kmer FTBFS in clean unstable chroot
Package: kmer Version: 0~20150903+r2013-4 Severity: serious Justification: FTBFS in clean chroot I cannot build kmer under both Debian experimental, and the debian unstable docker. ``` ^ In file included from atac-driver/alignOverlap/overlap.H:45, from atac-driver/alignOverlap/overlap-sort.C:19: atac-driver/alignOverlap/overlap-stats.H:64:29: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf(out, uint32FMT" "uint32FMT"\n", i, hist[i]); ^ ln -f /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process1.C ln -f /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process.C /root/kmer-0~20150903+r2013/atac-driver/alignOverlap/overlap-process2.C make[2]: *** No rule to make target '/root/kmer-0~20150903+r2013/atac-driver/libatac/libatac.a', needed by 'atac-driver/alignOverlap/overlap'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/root/kmer-0~20150903+r2013' make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2 make[1]: Leaving directory '/root/kmer-0~20150903+r2013' make: *** [debian/rules:21: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 ```
Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)
control: tag -1 -moreinfo Hi Adam, Intel has fixed the AMD CPU test failure. https://github.com/intel/mkl-dnn/issues/291 Let's upload the latest snapshot to experimental? https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.16+git20180820.f51304a-1.dsc PPA: https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages Dom: http://debomatic-amd64.debian.net/distribution#experimental/mkl-dnn/0.16+git20180820.f51304a-1/buildlog Salsa: https://salsa.debian.org/science-team/mkl-dnn Thanks! On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote: > On Thu, Aug 09, 2018 at 10:16:17AM +0000, Lumin wrote: > > * Package name: mkl-dnn > >Version : 0.15+git20180803.3f58c16-1 > >Upstream Author : intel > > Alas, the build flags use -march=native -mtune=native which is a big no-no. > The first makes the package crash on any processor lacking an extension that > was present on the build machine and was used by the compiler; unless some > kind of runtime detection is used, packages are allowed only the baseline > ISA for the architecture. As for -mtune=native, it makes the package build > unreproducibly, differing based on where it was compiled. Fixed in the updated package. > The second problem is that in the testsuite, test_convolution_format_any > fails (0/5 sub-tests). This might be related to my machine being: > vendor_id : AuthenticAMD > model name: AMD Phenom(tm) II X6 1055T Processor > > Log of the FTBFS attached. Fixed by Intel. > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job, > ⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato > ⢿⡄⠘⠷⠚⠋⠀ pancakes. Then the Polish couldn't decide which of his > ⠈⠳⣄ adjectives to use for the dish's name.
Bug#906732: intel-mkl: [INTL:fr] French translation
Hi jean-pierre giraud, Thank you for the translation but you seem to have forgotten to add the attachment. Best, lumin
Bug#906708: Bug#906753: Acknowledgement (GCC's -O2 optimization breaks floating point precision or something else)
This is the minimal code for repro #906753:
OK with -O0, FAIL with -O2 on i386, ppc64el, ...
masssq1 and masssq2 are computed from the same vector [1.1, 2.2, 3.3, 4.4],
but the results are different!
==
#include
#include // for swap
#include
namespace HepMC {
class FourVector {
public:
double m_x, m_y, m_z, m_t;
FourVector( double xin, double yin, double zin, double tin=0) : m_x(xin),
m_y(yin), m_z(zin), m_t(tin) {}
inline double m2() const {
return m_t*m_t - (m_x*m_x + m_y*m_y + m_z*m_z);
}
inline double m() const {
double mm = m2();
return mm < 0.0 ? -std::sqrt(-mm) : std::sqrt(mm);
}
};
} // HepMC
int main()
{
double eps = 1.e-15; // allowed differnce between doubles
// FourVector
HepMC::FourVector vector(1.1,2.2,3.3,4.4);
HepMC::FourVector v4(1.1,2.2,3.3,4.4);
//vector = v4;
double masssq1 = v4.m2();
double mass1 = v4.m();
double masssq2 = vector.m2();
double mass2 = vector.m();
if( fabs( masssq1 - masssq2 ) > eps ) {
std::cout << "different mass sq values: " << masssq1 << " " << masssq2 <<
std::endl;
std::cout << "difference is : " << ( masssq1 - masssq2 ) << std::endl;
}
return 0;
}
Bug#906754: don't skip tests for non-x86 architectures
Package: julia Version: 0.7.0-2 Severity: normal e.g. https://github.com/JuliaLang/julia/issues/27174 https://github.com/JuliaLang/julia/issues/28783 This will expose more problems instead of hide them.
Bug#906753: GCC's -O2 optimization breaks floating point precision or something else
Package: g++-8 Version: 8.2.0-4 Severity: serious Justification: -O2 results in different double precision number result. Affects: 906708 This bug is found in package src:hepmc, which currently FTBFS on i386, arm64, ppc64el and s390x. https://buildd.debian.org/status/package.php?p=hepmc - arm64: difference is : 3.55271e-15 - i386: difference is : 1.77636e-15 - ppc64el: difference is : 3.55271e-15 - s390x: difference is : 3.55271e-15 Data Matrix: * amd64 architecture + GCC-8: -O2 : OK -O0 : OK + Clang-6.0 -O2 : OK -O0 : OK * ppc64el architecture + GCC-8: -O2 : FTBFS because floating point precision beyond tolerance -O0 : OK + Clang-6.0: -O2 : OK -O0 : OK + GCC-7: -O2 : FTBFS + GCC-6: -O2 : FTBFS + GCC-5: -O2 : FTBFS * i386, arm64, s390x not tested. * In testSimpleVector.cc, the expected result of v4.m2() and vector.m2() are both 2.4253 . * -O2 and -O0 can be specified in DEB_CXXFLAGS_MAINT_APPEND * default compiler can be switched by simply e.g. export CC=clang export CXX=clang++ in debian/rules I wanted to trace into testSimpleVector.cc with gdb to find out what's going wrong. However this bug only occurs with -O2 option with which gdb cannot trace the C++ code line by line. Clang-6 doesn't FTBFS with the same compiler flags, so I consider this bug is an RC bug of GCC. I totally forgot how to dump the detail about gcc's -O2 option. Hence I'm not sure if gcc -O2 used something like -ffast-math .
Bug#906708: hepmc: FTBFS on i386 / arm64 / ppc64el / s390x
control: tags -1 +patch +confirmed > Fix attached. > - double eps = 1.e-15; // allowed differnce between doubles > + double eps = 4.e-15; // allowed difference between doubles No no no, please DON'T do this! This precision issue is triggered by a GCC optimization bug, and simply bumping floating point tolerance for scientific software especially physics software is bad The fix of this RC is to simply change the default compiler to Clang. Or disable -O2 optimization with -O0 the real patch: debian/rules: export CC=clang export CXX=clang++
Bug#906646: RFS: double-conversion/3.0.0+git20180802.4e8b3b5-1 [ITA, tensorflow deps]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "double-conversion" * Package name: double-conversion Version : 3.0.0+git20180802.4e8b3b5-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : libs It builds those binary packages: libdouble-conversion-dev - routines to convert IEEE floats to and from strings (development libdouble-conversion1 - routines to convert IEEE floats to and from strings To access further information about this package, please visit the following URL: https://mentors.debian.net/package/double-conversion Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/double-conversion/double-conversion_3.0.0+git20180802.4e8b3b5-1.dsc More information about hello can be obtained from 1. salsa git repo [branch: lumin/3.0.0 instead of master] https://salsa.debian.org/science-team/double-conversion 2. dom-amd64 build for sid/experimental http://debomatic-amd64.debian.net/distribution#unstable/double-conversion/3.0.0-1/buildlog autopkgtest is broken due to some debomatic reason. 3. dom-amd64 build + autopkgtest for ubuntu cosmic http://debomatic-amd64.debian.net/distribution#cosmic/double-conversion/3.0.0+git20180802.4e8b3b5-1u1/buildlog 4. ubuntu PPA cosmic build https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages amd64, arm64, armhf, i386, ppc64el, s390x [all OK] double-conversion is a Tensorflow dependency. I'm uploading a snapshot to archive instead of the latest release 3.0.0 because libtensorflow.so FTBFS with the stable release. Note, it appears that this package doesn't need a transition slot since there is no ABI change. (however upstream changed SOVERSION due to nonsence). This package should go into experimental first, and enter unstable only if I have finished the reverse dependency check. Afterall this package has a high popcon. Changes since the last upload: double-conversion (3.0.0+git20180802.4e8b3b5-1) experimental; urgency=medium * [O/ITA] Add myself to Uploaders. (Closes: #815264) * New upstream version snapshot 3.0.0+git20180802.4e8b3b5 + Note, the SOVERSION has been bumped to 3.0.0 in upstream's cmake build. However it was bumped only because they had changed the source directory layout, and ABI has not been changed. Hence, in debian/rules SOVERSION is left unchanged because bumping it doesn't make sense for Debian and would trigger an unnecessary rebuild of the reverse dependency tree. * Update Patches. + Refresh fix_m68k.patch . - Remove fix_riscv64.patch , fixed upstream. * Modify source paths in rules , *.install and debian/*.docs , following upstream's directory layout change. * Append hardening flags to rules. * Upgrade watch file to uscan version 4. * Homepage: Upstream project transferred to google. * Add autopkgtest control file to build and run upstream tests. * Bump Standards-Version to 4.2.0 (no change). * Add -I. to CPPFLAGS in order to avoid build failure in clean chroot.
Bug#906645: FTBFS due to "Dunno about this gcc"
Source: insighttoolkit4 Version: 4.13.0-dfsg1 Severity: serious Justification: FTBFS in sid/experimental. [ 14%] Building CXX object Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o cd /dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/vcl && /usr/bin/c++ -DVXL_LEGACY_ERROR_REPORTING -DVXL_WARN_DEPRECATED -DVXL_WARN_DEPRECATED_ONCE -Ditkvcl_EXPORTS -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/core -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/v3p/netlib -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/vcl -I/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD/Modules/ThirdParty/VNL/src/vxl/core -g -O2 -fdebug-prefix-map=/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/nifti -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wstrict-null-sentinel -w -fPIC -o CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o -c /dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_deprecated.cxx In file included from /dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_iostream.h:5, from /dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_deprecated.cxx:4: /dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/Modules/ThirdParty/VNL/src/vxl/vcl/vcl_compiler.h:90:4: error: #error "Dunno about this gcc" # error "Dunno about this gcc" ^ make[2]: *** [Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/build.make:66: Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/vcl_deprecated.cxx.o] Error 1 make[2]: Leaving directory '/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD' make[1]: *** [CMakeFiles/Makefile2:1636: Modules/ThirdParty/VNL/src/vxl/vcl/CMakeFiles/itkvcl.dir/all] Error 2 make[1]: Leaving directory '/dev/shm/rdepends/insighttoolkit4-4.13.0-dfsg1/BUILD' make: *** [Makefile:166: all] Error 2
Bug#815264: O: double-conversion -- routines to convert IEEE floats to and from strings
On Sat, Aug 18, 2018 at 07:23:48PM +0200, Sébastien Villemot wrote: > Hi Lumin, > > Le samedi 18 août 2018 à 15:16 +0000, Lumin a écrit : > > double-conversion is a tensorflow dependency and surprisingly it was > > orphaned. I will continue maintaining it within d-science team. > > Great! > > > However, in order to avoid embedding a copy of double-conversion source > > code in tensorflow source package, may I upload a snapshot[1] version of > > double-conversion specified by tensorflow? Then I only need to embed a > > copy of eigen3. > > You should probably check with reverse dependencies that it's ok to > package a snapshot. In particular, Qt5 depends on double-conversion, so > you should handle this package with care. libtensorflow.so FTBFS with double-conversion 3.0.0 so I need a snapshot version of double-conversion. Updated package has been prepared in a separate branch: g...@salsa.debian.org:science-team/double-conversion.git - lumin/3.0.0 Dom-amd64: experimental: http://debomatic-amd64.debian.net/distribution#experimental/double-conversion/3.0.0+git20180802.4e8b3b5-1/buildlog cosmic: http://debomatic-amd64.debian.net/distribution#cosmic/double-conversion/3.0.0+git20180802.4e8b3b5-1u1/autopkgtest PPA: https://launchpad.net/~lumin0/+archive/ubuntu/ppa/+packages I haven't checked API, but there is no ABI bump. Should I ask for a transition slot and bump ABI anyway? > Best, > > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name > ⠈⠳⣄ http://www.debian.org
Bug#905842: please consider uploading eigen3 3.3.5
On Sat, Aug 18, 2018 at 03:36:40PM +0200, Anton Gladky wrote: > Well, if the tensorflow deviation of eigen3 is too large, > I think it is allowed to use the embedded eigen3 for the > tensorflow. I looked up the changelog and there are only several commits between 3.3.5 and the snapshot version specified by tensorflow. If I didn't get debian's eigen3 (3.3.5) working with tensorflow, I'll embed one. > Anton > > > 2018-08-18 14:53 GMT+02:00 Lumin : > > On Sat, Aug 18, 2018 at 01:28:18PM +0200, Andreas Tille wrote: > >> Hi, > >> > >> On Fri, Aug 10, 2018 at 01:24:16PM +, Lumin wrote: > >> > > >> > So I'd suggest that upload the 3.3.5 version with the above ppc64el fix. > >> > >> I commited new upstream source to Git but there are quilt patches that > >> do not apply cleanly. I have no time to investigate this more deeply > >> and left a note in d/changelog about this work item to be done. Sorry > >> for not beeing more helpful - feel free to take over > > > > Thanks Andreas, Anton is working on newer eigen3, see #906126 > > > > importing 3.3.5 is not enough for building tensorflow. I need not > > only the following function signature in > > unsupported/Eigen/CXX11/src/ThreadPool/NonBlockingThreadPool.h > > > >25 ThreadPoolTempl(int num_threads, bool allow_spinning, > >26 Environment env = Environment()) > > > > But bitbucket is very hard to use and I struggled for a long while > > with it but I still cannot find out which commit introduced this change. > > > > > > @Anton: > > > > I think I can make a differential between eigen 3.3.5 and the eigen > > snapshot that tensorflow used, and patch the eigen library when building > > tensorflow. Since eigen3 is a header only library, this is not hard to > > achive. > > > > I'm able to build libtensorflow.so and the python interface library > > with the patch series https://github.com/tensorflow/tensorflow/pull/21699 , > > embedded eigen3 and embedded double-precision. > > However the python package still misses some python dependencies. > > > >> > >> Andreas. > >> > >> -- > >> http://fam-tille.de
Bug#905842: please consider uploading eigen3 3.3.5
On Sat, Aug 18, 2018 at 01:28:18PM +0200, Andreas Tille wrote: > Hi, > > On Fri, Aug 10, 2018 at 01:24:16PM +0000, Lumin wrote: > > > > So I'd suggest that upload the 3.3.5 version with the above ppc64el fix. > > I commited new upstream source to Git but there are quilt patches that > do not apply cleanly. I have no time to investigate this more deeply > and left a note in d/changelog about this work item to be done. Sorry > for not beeing more helpful - feel free to take over Thanks Andreas, Anton is working on newer eigen3, see #906126 importing 3.3.5 is not enough for building tensorflow. I need not only the following function signature in unsupported/Eigen/CXX11/src/ThreadPool/NonBlockingThreadPool.h 25 ThreadPoolTempl(int num_threads, bool allow_spinning, 26 Environment env = Environment()) But bitbucket is very hard to use and I struggled for a long while with it but I still cannot find out which commit introduced this change. @Anton: I think I can make a differential between eigen 3.3.5 and the eigen snapshot that tensorflow used, and patch the eigen library when building tensorflow. Since eigen3 is a header only library, this is not hard to achive. I'm able to build libtensorflow.so and the python interface library with the patch series https://github.com/tensorflow/tensorflow/pull/21699 , embedded eigen3 and embedded double-precision. However the python package still misses some python dependencies. > > Andreas. > > -- > http://fam-tille.de
Bug#815264: O: double-conversion -- routines to convert IEEE floats to and from strings
control: owner -1 control: retitle -1 ITA: double-conversion -- routines to convert IEEE floats to and from strings double-conversion is a tensorflow dependency and surprisingly it was orphaned. I will continue maintaining it within d-science team. However, in order to avoid embedding a copy of double-conversion source code in tensorflow source package, may I upload a snapshot[1] version of double-conversion specified by tensorflow? Then I only need to embed a copy of eigen3. The version number will be 3.0+git20180413.3992066 . [1] 3992066a95b823efc8ccc1baf82a1cfc73f6e9b8
Bug#906425: RFS: sleef/3.3-1 [ITP] -- vectorized math library, pytorch deps.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "sleef" * Package name: sleef Version : 3.3-1 Upstream Author : Naoki Shibata * URL : sleef.org * License : Boost Software License 1.0 Section : math It builds those binary packages: libsleef-dev - SLEEF Vectorized Math Library (development) libsleef3 - SLEEF Vectorized Math Library (libraries) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sleef Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sleef/sleef_3.3-1.dsc More information about hello can be obtained from 1. git repo: https://salsa.debian.org/lumin-guest/sleef 2. dom-amd64 test: http://debomatic-amd64.debian.net/distribution#experimental/sleef/3.3-1/buildlog Changes since the last upload: sleef (3.3-1) experimental; urgency=medium * Initial release. (Closes: #906248)
Bug#906252: uscan: github user/project/tags page no longer works
control: severity -1 important This problem started affecting DDPO pages. All watch files used similar web page will get a blank result.
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
On Thu, Aug 16, 2018 at 01:45:14PM +0100, Ian Jackson wrote:
> Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and
> LLVM-6.0"):
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
>
> This looks quite annoying. The basic pattern here is that the porter
> may need to install modified build-deps. This seems like it must come
> up all the time. DSA, do you have any suggestions ?
Yes, sadly. However if DSA grant us the permission to install a
customized package, we can package e.g. a setuid program to obtain
the root shell within chroot.
BTW the schroot usage page (https://dsa.debian.org/doc/schroot/)
should really mention the tricks about env vars. I've submitted bug here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906313
> I was going to suggest that if the llvm-toolchain maintainers agree,
> perhaps the package with the proposed patch could be uploaded to
> experimental. But in my ad-hoc tests I couldn't get dd-schroot-cmd to
> even install the package from experimental.
Frédéric has just verified the proposed patch and it's working as
expected. Thank you again @Frédéric Bonnard !
> Ian.
Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0
Hi Frédéric,
Thank you very much for your help!
I've filed the bug for LLVM
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906314
and had it blocking julia's ppc64el build failure.
And have requested for a ppc64el vm. Next time I should be able to
do the ppc64el build by myself :-)
On Thu, Aug 16, 2018 at 05:37:06PM +0200, Frédéric Bonnard wrote:
> Hi Mo Zhou,
>
> On Thu, 16 Aug 2018 08:38:04 +, Mo Zhou wrote:
> > Package: wnpp
> > Severity: normal
> >
> > I request assistance with maintaining the julia package.
> > Specifically I need a ppc64el porter (or anyone who has root access to
> > a ppc64el box) to help me:
> >
> > 1. Apply patch[1] to Debian's llvm-toolchain-6.0 (= 1:6.0.1-4) and build
> > it.
>
> I fetched this https://reviews.llvm.org/D43781
>
> > 2. Install the resulting llvm-6.0-dev (= 1:6.0.1-5).
> >
> > 3. dget julia 0.7.0-2 and build Julia for ppc64el.
> >
> > 4. if (!llvm-ftbfs && !julia-ftbfs) {
>
> I got there : both built fine.
> I just had to avoid building in a schroot because of this :
>
> ---
> make[3]: Entering directory '/build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0'
> Warning: git information unavailable; versioning information limited
> cd /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/base && if !
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/bin/julia -O3 -C "native"
> --output-o
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys-o.a.tmp
> --startup-file=no --warn-overwrite=yes --sysimage
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/lib/powerpc64le-linux-gnu/julia/sys.ji;
> then echo '*** This error is usually fixed by running `make clean`. If the
> error persists, try `make cleanall`. ***'; false; fi
> Generating precompile statements...ERROR: LoadError: Failed to open PTY master
> Stacktrace:
> [1] error(::String) at ./error.jl:33
> [2] open_fake_pty at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:14
> [inlined]
> [3] with_fake_pty(::getfield(Main.anonymous,
> Symbol("##3#9")){String,Base.GenericIOBuffer{Array{UInt8,1}},Base.GenericIOBuffer{Array{UInt8,1}},String})
> at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/usr/share/julia/test/testhelpers/FakePTYs.jl:30
> [4] (::getfield(Main.anonymous,
> Symbol("##2#8")){Float64,Module,String})(::String, ::IOStream) at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:81
> [5] mktemp(::getfield(Main.anonymous,
> Symbol("##2#8")){Float64,Module,String}, ::String) at ./file.jl:576
> [6] mktemp at ./file.jl:574 [inlined]
> [7] generate_precompile_statements() at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:78
> [8] top-level scope at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:144
> in expression starting at
> /build/llvm-toolchain-6.0-0CdyF5/julia-0.7.0/contrib/generate_precompile.jl:4
> ---
>
> which is unrelated to the problem you had but to workaround I built in a
> fresh ppc64el unstable vm (probably due to bug #817236 and my schroot being
> too old
> to be created with the fix)
>
> >
> > 1. clone #905807 for llvm-6.0 and remove the +moreinfo tag
> > 2. pull the experimental branch from
> > https://salsa.debian.org/julia-team/julia
> > and see if the patched llvm-6.0 is also able to build julia 1.0.0
>
> this one builds fine as well.
> For now, I won't have time to re-assign the bug on llvm. I'll check that
> tomorrow.
>
> > } elif (!llvm-ftbfs && julia-ftbfs) {
> >
> > 1. find out which patch actually fixes julia's build failure
> >
> > https://github.com/JuliaLang/julia/blob/master/deps/llvm.mk#L482-L509
> >
> > } else { .. }
> >
> > I tried to setup a ppc64el chroot with qemu, and immediately find it
> > impractical for my laptop.
> >
> > I tried to do it on launchpad (Ubuntu PPA/cosmic), and lauchpad told me
> > "Sorry, something just went wrong in Launchpad." during registration.
> >
> > I tried to think of applying for the access to debian's ppc64el porterbox
> > but it appears to be impossible for a normal user to install the resulting
> > package and build another package. Although maybe I can do some hacks on
> > PATH and LD_LIBRARY_PATH but that's dirty.
>
> Yes, that's a security related limitation of porter boxes which
> sometimes makes them unhelpful sadly.
>
> FYI, you may request a ppc64el vm there :
> http://openpower.ic.unicamp.br/minicloud/
>
> > So I gave up and wrote this RFH. That begin said, Julia's ppc64el port
> > is indeed supported by upstream, and it is worthwhile to keep Julia for
> > ppc64el such a powerful architecture.
> >
> > Thanks in advance.
>
> Thanks a bunch for this work :)
>
> F.
>
> >
> > [1] https://bugs.de
Bug#906314: llvm-6.0 unable to build julia 0.7/1.0
Package: llvm-6.0-dev Version: 1:6.0.1-4 Severity: important Justification: blocking RC bug Control: block 905807 by -1 Control: tag -1 +patch +confirmed Debian's llvm should add this patch https://reviews.llvm.org/D43781 And this patch has been verified by Frédéric https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906265#30 With this patch we can build Julia on ppc64el again.
Bug#906313: improvement to the schroot usage doc on porterbox https://dsa.debian.org/doc/schroot/
Package: www.debian.org Severity: wishlist X-Debbugs-CC: DSA According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906265#20 , the schroot should mention the env var tricks when the porter needs to build a modified B-D and then build another package on top of it.
Bug#906252: Acknowledgement (uscan: github user/project/tags page no longer works)
A temporary fix could be to use the user/project/releases page, but this is sometimes problematic if the first page is full of alpha or beta releases.
Bug#906252: uscan: github user/project/tags page no longer works
Package: devscripts
Severity: normal
Justification: template in manpage is not working
I'm not sure what happend but it appears that github has changed something.
For example, when I fetch the tags page of julia:
~/p/j/julia ❯❯❯ curl -s https://github.com/JuliaLang/julia/tags
v1.0.0
v1.0.0-rc1
v0.7.0
v0.7.0-rc3
v0.7.0-rc2
v0.7.0-rc1
v0.7.0-beta2
v0.7.0-beta
v0.7.0-alpha
and the result is NO matching pattern found. Several days ago the same
watch file is still working.
~/p/j/julia ❯❯❯ uscan --verbose --debug
uscan info: uscan (version 2.18.3) See uscan(1) for help
uscan info: Scan watch files in .
uscan debug: Found ./debian
uscan debug: Found ./.git/refs/tags/debian
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="julia" version="1.0.0-1" (as seen in debian/changelog)
uscan info: package="julia" version="1.0.0" (no epoch/revision)
uscan info: Check debian/watch and debian/changelog in ./.git/refs/tags
uscan info: ./debian/changelog sets package="julia" version="1.0.0"
uscan info: Process watch file at: debian/watch
package = julia
version = 1.0.0
pkg_dir = .
uscan info: opts:
filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%julia-$1.tar.gz%
uscan info: line: https://github.com/JuliaLang/julia/tags
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
uscan info: Parsing
filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%julia-$1.tar.gz%
uscan info: line: https://github.com/JuliaLang/julia/tags
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
uscan debug: $options{'pgpmode'}=default, $options{'pgpsigurlmangle'}=undef
uscan info: Last orig.tar.* tarball version (from debian/changelog): 1.0.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 1.0.0
uscan debug: watch file has:
$base= https://github.com/JuliaLang/julia/tags
$filepattern = (?:.*?/)?v?(\d[\d.]*)\.tar\.gz
$lastversion = 1.0.0
$action = uupdate
mode = http
pgpmode = default
versionmode = newer
$site= https://github.com
$basedir = /JuliaLang/julia/tags
uscan info: Requesting URL:
https://github.com/JuliaLang/julia/tags
uscan debug: received content:
v1.0.0
v1.0.0-rc1
v0.7.0
v0.7.0-rc3
v0.7.0-rc2
v0.7.0-rc1
v0.7.0-beta2
v0.7.0-beta
v0.7.0-alpha
[End of received content] by HTTP
uscan debug: processed content:
v1.0.0
v1.0.0-rc1
v0.7.0
v0.7.0-rc3
v0.7.0-rc2
v0.7.0-rc1
v0.7.0-beta2
v0.7.0-beta
v0.7.0-alpha
[End of processed content] by fix bad HTML code
uscan info: Matching pattern:
(?:(?:https://github.com)?\/JuliaLang\/julia\/tags)?(?:.*?/)?v?(\d[\d.]*)\.tar\.gz
uscan warn: In debian/watch no matching files for watch line
https://github.com/JuliaLang/julia/tags (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian
uupdate
uscan info: Scan finished
This is my watch file:
version=4
opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%julia-$1.tar.gz%" \
https://github.com/JuliaLang/julia/tags \
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
Bug#906248: ITP: sleef -- SLEEF Vectorized Math Library
Package: wnpp Severity: wishlist Owner: Lumin * Package name: sleef Version : 3.3 Upstream Author : SLEEF Project. * URL : https://sleef.org/ https://github.com/shibatch/sleef * License : Boost software license Programming Lang: C + intrinsics Description : SLEEF Vectorized Math Library Section : Science Sleef is one of PyTorch/Caffe2 deps.
Bug#906206: RFS: chafa/0.9.0+git20180731.5ddfe4c-3 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "chafa" * Package name: chafa Version : 0.9.0+git20180731.5ddfe4c-3 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : graphics It builds those binary packages: chafa - Image-to-text converter supporting a wide range of symbols, etc. libchafa-dev - development files for image-to-text converter chafa libchafa0 - library for image-to-text converter chafa To access further information about this package, please visit the following URL: https://mentors.debian.net/package/chafa Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-3.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/chafa/0.9.0+git20180731.5ddfe4c-3/buildlog changes: chafa (0.9.0+git20180731.5ddfe4c-3) unstable; urgency=medium * Package libchafa-dev should Depend on libchafa0 . (Closes: #906190) * Cherry-pick patch from upstream-git: Make chafa --version return 0. (+ patches/0001-chafa-Return-TRUE-0-after-print_version.patch) * Update autopkgtest control file to avoid test failure.
Bug#905970: RFS: chafa/0.9.0+git20180731.5ddfe4c-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "chafa" * Package name: chafa Version : 0.9.0+git20180731.5ddfe4c-2 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : graphics It builds those binary packages: chafa - Image-to-text converter supporting a wide range of symbols, etc. libchafa-dev - development files for image-to-text converter chafa libchafa0 - library for image-to-text converter chafa To access further information about this package, please visit the following URL: https://mentors.debian.net/package/chafa Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-2.dsc More information about hello can be obtained from dom-amd64 and dom-i386 is malfunctional currently. However I've tested the i386 build in a i386 chroot. Changes since the last upload: chafa (0.9.0+git20180731.5ddfe4c-2) unstable; urgency=medium * Port Chafa to *-i386 architectures. (+ port-i386.patch) * Add -DCHAFA_REG_BIT32 to CFLAGS when building on *-i386 .
Bug#905884: closed by Adam Borowski (Re: Bug#905884: RFS: chafa/0.9.0+git20180731.5ddfe4c-1 [ITP])
On Sat, Aug 11, 2018 at 11:00:03AM +, Debian Bug Tracking System wrote: > On Sat, Aug 11, 2018 at 06:26:46AM +0000, Lumin wrote: > > > > * Package name: chafa > >Version : 0.9.0+git20180731.5ddfe4c-1 > > * URL : https://hpjansson.org/chafa/ > > * License : LGPL-3 > > > It builds those binary packages: > > > > chafa - Image-to-text converter supporting a wide range of symbols, etc. > > libchafa-dev - development files for image-to-text converter chafa > > libchafa0 - library for image-to-text converter chafa > > > chafa (0.9.0+git20180731.5ddfe4c-1) unstable; urgency=low > > > > * Initial release. (Closes: #905882) > > Awesome! Chafa was on my TODO list, I just lacked the tuits to package it. > And I really prefer work to be done by people who are not me. :) > > It's drastically better than catimg for Unicode images, and than caca for > plain ASCII. I came across Chafa several hours ago as a catimg user, and I was surprised by this brilliant tool. Chafa provides much better functionality compared to CACA and catimg, and supports many image formats. > In NEW. Thanks!
Bug#905884: RFS: chafa/0.9.0+git20180731.5ddfe4c-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "chafa" * Package name: chafa Version : 0.9.0+git20180731.5ddfe4c-1 Upstream Author : Hans Petter Jansson * URL : https://hpjansson.org/chafa/ * License : LGPL-3 Section : graphics It builds those binary packages: chafa - Image-to-text converter supporting a wide range of symbols, etc. libchafa-dev - development files for image-to-text converter chafa libchafa0 - library for image-to-text converter chafa To access further information about this package, please visit the following URL: https://mentors.debian.net/package/chafa Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/chafa/chafa_0.9.0+git20180731.5ddfe4c-1.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/chafa/0.9.0+git20180731.5ddfe4c-1/buildlog chafa (0.9.0+git20180731.5ddfe4c-1) unstable; urgency=low * Initial release. (Closes: #905882)
Bug#905882: ITP: chafa -- Image-to-text converter supporting a wide range of symbols and palettes, transparency, animations, etc.
Package: wnpp Severity: wishlist Owner: lumin * Package name: chafa Version : 0.9.0+git20180731.5ddfe4c Upstream Author : Hans Petter Jansson * URL : https://hpjansson.org/chafa/ * License : LGPL-3.0+ Programming Lang: C Description : Image-to-text converter supporting a wide range of symbols and palettes, transparency, animations, etc.
Bug#905622: julia 0.7.0~rc3 is available
close -1 already in unstable
Bug#905849: problematic symlink /usr/lib/x86_64-linux-gnu/julia/.so found in libjulia0.7
Package: libjulia0.7 Version: 0.7.0~beta2-1 Severity: important ~ ❯❯❯ dpkg -L libjulia0.7 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/julia /usr/lib/x86_64-linux-gnu/julia/libccalltest.so /usr/lib/x86_64-linux-gnu/julia/libsuitesparse_wrapper.so /usr/lib/x86_64-linux-gnu/julia/sys.so /usr/lib/x86_64-linux-gnu/libjulia.so.0.7.0 /usr/share /usr/share/doc /usr/share/doc/libjulia0.7 /usr/share/doc/libjulia0.7/NEWS.Debian.gz /usr/share/doc/libjulia0.7/changelog.Debian.gz /usr/share/doc/libjulia0.7/changelog.gz /usr/share/doc/libjulia0.7/copyright /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libjulia0.7 /usr/lib/x86_64-linux-gnu/julia/.so /usr/lib/x86_64-linux-gnu/julia/libLLVM.so /usr/lib/x86_64-linux-gnu/julia/libamd.so /usr/lib/x86_64-linux-gnu/julia/libcamd.so /usr/lib/x86_64-linux-gnu/julia/libccolamd.so /usr/lib/x86_64-linux-gnu/julia/libcholmod.so /usr/lib/x86_64-linux-gnu/julia/libcolamd.so /usr/lib/x86_64-linux-gnu/julia/libcurl.so /usr/lib/x86_64-linux-gnu/julia/libdSFMT.so /usr/lib/x86_64-linux-gnu/julia/libgit2.so /usr/lib/x86_64-linux-gnu/julia/libgmp.so /usr/lib/x86_64-linux-gnu/julia/libmbedcrypto.so /usr/lib/x86_64-linux-gnu/julia/libmbedtls.so /usr/lib/x86_64-linux-gnu/julia/libmbedx509.so /usr/lib/x86_64-linux-gnu/julia/libmpfr.so /usr/lib/x86_64-linux-gnu/julia/libopenblas.so /usr/lib/x86_64-linux-gnu/julia/libopenlibm.so /usr/lib/x86_64-linux-gnu/julia/libopenspecfun.so /usr/lib/x86_64-linux-gnu/julia/libpcre2-8.so /usr/lib/x86_64-linux-gnu/julia/libspqr.so /usr/lib/x86_64-linux-gnu/julia/libssh2.so /usr/lib/x86_64-linux-gnu/julia/libsuitesparseconfig.so /usr/lib/x86_64-linux-gnu/julia/libumfpack.so /usr/lib/x86_64-linux-gnu/julia/libunwind.so /usr/lib/x86_64-linux-gnu/julia/libutf8proc.so /usr/lib/x86_64-linux-gnu/libjulia.so.0.7 ~ ❯❯❯ file /usr/lib/x86_64-linux-gnu/julia/.so /usr/lib/x86_64-linux-gnu/julia/.so: symbolic link to ../libfftw3_threads.so.3
Bug#905843: lintian recognized "allow-stderr" as a non-standard autopkgtest restriction
Package: lintian Version: 2.5.96 Severity: normal "allow-stderr" is a standard value according to the given document. P: julia source: unknown-runtime-tests-restriction allow-stderr paragraph starting at line 2 N: N:A paragraph in debian/tests/control mentions a non-standard value for N:the Restrictions field. Though allowed, this may indicate an error, as N:the whole paragraph will be ignored. N: N:Refer to N: https://salsa.debian.org/ci-team/autopkgtest/tree/master/doc/README.package-tests.rst N:for details. N: N:Severity: pedantic, Certainty: wild-guess N: N:Check: testsuite, Type: source
Bug#905842: please consider uploading eigen3 3.3.5
Package: libeigen3-dev Version: 3.3.4-4 Severity: wishlist I tried to build TensorFlow with the eigen3 library shipped by system instead of a downloaded one during build time but it failed. TensorFlow upstream uses the fd6845384b86 (2018-06-22) commit currently. https://bitbucket.org/eigen/eigen/pull-requests/410 https://github.com/tensorflow/tensorflow/pull/20254 The previous commit the TensorFlow used is e5e305a158a0 (2018-06-21), which seems to be included in the 3.3.5 release. So I'd suggest that upload the 3.3.5 version with the above ppc64el fix.
Bug#905826: libjulia depends on libblas.so.3 instead of openblas?
Package: julia Version: 0.7.0-1 Severity: wishlist A user suggested that we build julia against libblas.so.3 instead of openblas, as said here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903879#10 > The current version of gimp is incompatible with openblas (#903514). > > julia and libjulia0.6 currently depend on libopenblas-base. I suggest that > they should instead depend on the virtual packages libblas.so.3 and > liblapack.so.3 (which can also be provided by liblapack3 and libblas3, > resp., and libatlas3-base provides both) - assuming of course that julia > will work that way. However I have literally no interest to build julia against netlib blas when OpenBLAS is available.
Bug#903879: Add openblas 0.3.1 dgesvd regression test to julia
control: close -1 this bug is rotten and is not useful anymore.
Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)
control: tag -1 +moreinfo On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote: > On Thu, Aug 09, 2018 at 10:16:17AM +0000, Lumin wrote: > > * Package name: mkl-dnn > >Version : 0.15+git20180803.3f58c16-1 > >Upstream Author : intel > > Alas, the build flags use -march=native -mtune=native which is a big no-no. > The first makes the package crash on any processor lacking an extension that > was present on the build machine and was used by the compiler; unless some > kind of runtime detection is used, packages are allowed only the baseline > ISA for the architecture. As for -mtune=native, it makes the package build > unreproducibly, differing based on where it was compiled. My bad, I overlooked the two flags. The cmake files have been patched in master branch of packaging repo. https://salsa.debian.org/science-team/mkl-dnn/commit/6e0a9bea677d398ee23ac9c2f84c3551d100a6d4 http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog > The second problem is that in the testsuite, test_convolution_format_any > fails (0/5 sub-tests). This might be related to my machine being: > vendor_id : AuthenticAMD > model name: AMD Phenom(tm) II X6 1055T Processor Well, I have been waiting for intel to fix test failures for a long time. Finally the snapshot 0.15+git20180803.3f58c16 doesn't fail any test on dom-amd64 (E5 2699v?) and my I5-7440HQ, but now it failed on AMD cpu ... > Log of the FTBFS attached. Thanks for the log, I've forwarded it to upstream. https://github.com/intel/mkl-dnn/issues/291 I shouldn't let any test failure from mkl-dnn pass, so we have to wait for upstream to fix the problem. Fortunately, TensorFlow can be compiled with or without mkl-dnn. It doesn't matter if the initial upload of TensorFlow is not linked against mkl-dnn. The difference that mkl-dnn would bring to TensorFlow is computation speed-up.
Bug#905807: julia 0.7.0-1 doesn't build on ppc64el
Package: julia Version: 0.7.0-1 Severity: important Control: tag -1 +patch +moreinfo https://github.com/JuliaLang/julia/issues/22650 https://github.com/JuliaLang/julia/pull/26218 I don't have any ppc64el porter to test the LLVM patch. Once the patch is confirmed, this bug should be reassigned to LLVM, with the moreinfo tag dropped.
Bug#905785: elvish crashed after pressing "Ctrl + n" twice
Package: elvish Version: 0.12+ds1-1 Severity: normal We have a 100% chance to reproduce this crash. 1. $ elvish 2. type Ctrl + n twice 3. elvish crashed. ~ ❯❯❯ elvish ~> runtime error: invalid memory address or nil pointer dereference goroutine 1 [running]: github.com/elves/elvish/sys.DumpStack(0xc42033c8d8, 0x1) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/sys/dumpstack.go:10 +0xa2 github.com/elves/elvish/program/shell.rescue() /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/program/shell/shell.go:60 +0xc5 panic(0x87e080, 0xbbc240) /usr/lib/go-1.10/src/runtime/panic.go:502 +0x229 github.com/elves/elvish/eval.catch(0xc42033d748, 0xc42022c420) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/eval/frame.go:190 +0x266 panic(0x87e080, 0xbbc240) /usr/lib/go-1.10/src/runtime/panic.go:502 +0x229 github.com/elves/elvish/edit/edcore.(*navigation).List(0xc42017fe00, 0x2b, 0xc42017fe00, 0x7f6e37627258) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/navigation.go:346 +0x80 github.com/elves/elvish/edit/edcore.(*editorRenderer).Render(0xc42028ade0, 0xc4200a25f0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/render.go:242 +0x10b4 github.com/elves/elvish/edit/ui.Render(0x970700, 0xc42028ade0, 0x55, 0x971660) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/ui/render.go:16 +0x10b github.com/elves/elvish/edit/edcore.(*editor).refresh(0xc420204000, 0x970101, 0xc42017fef0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/edit.go:268 +0x2db github.com/elves/elvish/edit/edcore.(*editor).CallFn(0xc420204000, 0x970780, 0xc42017fef0, 0x0, 0x0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/api.go:121 +0x27e github.com/elves/elvish/edit/edcore.(*navigation).defaultFn(0xc42017fe00, 0xc420204000) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/navigation.go:165 +0xbf github.com/elves/elvish/edit/edcore.initNavigation.func4() /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/navigation.go:65 +0x33 reflect.Value.call(0x84a480, 0xc420180560, 0x13, 0x90d4f8, 0x4, 0x0, 0x0, 0x0, 0x60, 0x84a480, ...) /usr/lib/go-1.10/src/reflect/value.go:447 +0x969 reflect.Value.Call(0x84a480, 0xc420180560, 0x13, 0x0, 0x0, 0x0, 0x7f6e46213000, 0x0, 0xc4201cc000) /usr/lib/go-1.10/src/reflect/value.go:308 +0xa4 github.com/elves/elvish/eval.(*BuiltinFn).Call(0xc42017ff40, 0xc42022c420, 0x0, 0x0, 0x0, 0xc420196210, 0x8ecf00, 0xc420597700) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/eval/builtin_fn.go:184 +0x55c github.com/elves/elvish/eval.(*Frame).Call(0xc42022c420, 0x970780, 0xc42017ff40, 0x0, 0x0, 0x0, 0xc420196210, 0x0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/eval/frame.go:143 +0xbb github.com/elves/elvish/edit/edcore.(*editor).CallFn(0xc420204000, 0x970780, 0xc42017ff40, 0x0, 0x0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/api.go:115 +0x257 github.com/elves/elvish/edit/edcore.(*editor).ReadLine(0xc420204000, 0x0, 0x0, 0x0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/edit/edcore/edit.go:500 +0x9af github.com/elves/elvish/program/shell.interact.func1(0x895fc0, 0xc4202a0a60, 0x13, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/program/shell/interact.go:41 +0x2f github.com/elves/elvish/program/shell.interact(0xc4201a4320, 0xc420024340, 0x13, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/program/shell/interact.go:51 +0x219 github.com/elves/elvish/program/shell.(*Shell).Main(0xc42006ce40, 0xc420092170, 0x0, 0x0, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/program/shell/shell.go:48 +0x1a7 github.com/elves/elvish/program.Main(0xc420092170, 0x1, 0x1, 0x0) /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/program/program.go:119 +0x180 main.main() /build/elvish-AbOowp/elvish-0.12+ds1/obj-x86_64-linux-gnu/src/github.com/elves/elvish/main.go:14 +0x45 goroutine 19 [syscall]: os/signal.signal_recv(0x0) /usr/lib/go-1.10/src/runtime/sigqueue.go:139 +0xa6 os/signal.loop() /usr/lib/go-1.10/src/os/signal/signal_unix.go:22 +0x22 created by os/signal.init.0 /usr/lib/go-1.10/src/os/signal/sig
Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)
Package: sponsorship-requests Severity: wishlist Disclaimer: Intel made some confusing naming. I should point out that mkl-dnn is a free software, which can be independently compiled and used without any component from intel-mkl . Without linking against intel-mkl, we would get a suboptimal performance, but intel claimed that they are trying to reduce the performance gap. 1. [Apache-2.0] mkl-dnn: Intel Math Kernel Library - Deep Neural Network 2. [non-free] intel-mkl: Intel Math Kernel Library intel-mkl contains another set of dnn api (mkl_dnn.h) but let's ignore it. Dear mentors, I am looking for a sponsor for my package "mkl-dnn" * Package name: mkl-dnn Version : 0.15+git20180803.3f58c16-1 Upstream Author : intel * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libmkldnn-dev - Math Kernel Library for Deep Neural Networks (dev) libmkldnn-doc - Math Kernel Library for Deep Neural Networks (doc) libmkldnn0 - Math Kernel Library for Deep Neural Networks (lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mkl-dnn Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mkl-dnn/mkl-dnn_0.15+git20180803.3f58c16-1.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog Changes since the last upload: mkl-dnn (0.15+git20180803.3f58c16-1) unstable; urgency=low * Initial release. (Closes: #894411)
Bug#905397: Unable to build Julia 0.7.0~rc2 due to illegal inttoptr
control: tag -1 +confirmed +patch
We have successfully built Julia with the patched llvm-6.0 .
Please merge the two patches and update the llvm package.
* llvm-D49832-SCEVPred.patch
* llvm-rL323946-LSRTy.patch
They come from Julia's commit df451468a14e0b0f7985f8396a6c15ef5a411422
commit 98592fcc61307968f7df1362771534595a1e1c21
Author: Keno Fischer
Date: Wed Jul 25 19:29:02 2018 -0400
[SCEV] Don't expand Wrap predicate using inttoptr in ni addrspaces
Summary:
In non-integral address spaces, we're not allowed to introduce inttoptr/ptrtoint
intrinsics. Instead, we need to expand any pointer arithmetic as geps on the
base pointer. Luckily this is a common task for SCEV, so all we have to do here
is hook up the corresponding helper function and add test case.
Fixes PR38290
Reviewers: reames, sanjoy
Subscribers: javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D49832
diff --git a/lib/Analysis/ScalarEvolutionExpander.cpp b/lib/Analysis/ScalarEvolutionExpander.cpp
index 7f76f057216..f441a3647fb 100644
--- a/lib/Analysis/ScalarEvolutionExpander.cpp
+++ b/lib/Analysis/ScalarEvolutionExpander.cpp
@@ -2157,8 +2157,9 @@ Value *SCEVExpander::generateOverflowCheck(const SCEVAddRecExpr *AR,
const SCEV *Step = AR->getStepRecurrence(SE);
const SCEV *Start = AR->getStart();
+ Type *ARTy = AR->getType();
unsigned SrcBits = SE.getTypeSizeInBits(ExitCount->getType());
- unsigned DstBits = SE.getTypeSizeInBits(AR->getType());
+ unsigned DstBits = SE.getTypeSizeInBits(ARTy);
// The expression {Start,+,Step} has nusw/nssw if
// Step < 0, Start - |Step| * Backedge <= Start
@@ -2170,11 +2171,12 @@ Value *SCEVExpander::generateOverflowCheck(const SCEVAddRecExpr *AR,
Value *TripCountVal = expandCodeFor(ExitCount, CountTy, Loc);
IntegerType *Ty =
- IntegerType::get(Loc->getContext(), SE.getTypeSizeInBits(AR->getType()));
+ IntegerType::get(Loc->getContext(), SE.getTypeSizeInBits(ARTy));
+ Type *ARExpandTy = DL.isNonIntegralPointerType(ARTy) ? ARTy : Ty;
Value *StepValue = expandCodeFor(Step, Ty, Loc);
Value *NegStepValue = expandCodeFor(SE.getNegativeSCEV(Step), Ty, Loc);
- Value *StartValue = expandCodeFor(Start, Ty, Loc);
+ Value *StartValue = expandCodeFor(Start, ARExpandTy, Loc);
ConstantInt *Zero =
ConstantInt::get(Loc->getContext(), APInt::getNullValue(DstBits));
@@ -2197,8 +2199,21 @@ Value *SCEVExpander::generateOverflowCheck(const SCEVAddRecExpr *AR,
// Compute:
// Start + |Step| * Backedge < Start
// Start - |Step| * Backedge > Start
- Value *Add = Builder.CreateAdd(StartValue, MulV);
- Value *Sub = Builder.CreateSub(StartValue, MulV);
+ Value *Add = nullptr, *Sub = nullptr;
+ if (ARExpandTy->isPointerTy()) {
+PointerType *ARPtrTy = cast(ARExpandTy);
+const SCEV *MulS = SE.getSCEV(MulV);
+const SCEV *const StepArray[2] = {MulS, SE.getNegativeSCEV(MulS)};
+Add = Builder.CreateBitCast(
+expandAddToGEP(&StepArray[0], &StepArray[1], ARPtrTy, Ty, StartValue),
+ARPtrTy);
+Sub = Builder.CreateBitCast(
+expandAddToGEP(&StepArray[1], &StepArray[2], ARPtrTy, Ty, StartValue),
+ARPtrTy);
+ } else {
+Add = Builder.CreateAdd(StartValue, MulV);
+Sub = Builder.CreateSub(StartValue, MulV);
+ }
Value *EndCompareGT = Builder.CreateICmp(
Signed ? ICmpInst::ICMP_SGT : ICmpInst::ICMP_UGT, Sub, StartValue);
diff --git a/test/Analysis/LoopAccessAnalysis/wrapping-pointer-ni.ll b/test/Analysis/LoopAccessAnalysis/wrapping-pointer-ni.ll
new file mode 100644
index 000..ddcf5e1a195
--- /dev/null
+++ b/test/Analysis/LoopAccessAnalysis/wrapping-pointer-ni.ll
@@ -0,0 +1,73 @@
+; RUN: opt -loop-versioning -S < %s | FileCheck %s -check-prefix=LV
+
+; NB: addrspaces 10-13 are non-integral
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:10:11:12:13"
+
+; This matches the test case from PR38290
+; Check that we expand the SCEV predicate check using GEP, rather
+; than ptrtoint.
+
+%jl_value_t = type opaque
+%jl_array_t = type { i8 addrspace(13)*, i64, i16, i16, i32 }
+
+declare i64 @julia_steprange_last_4949()
+
+define void @"japi1_align!_9477"(%jl_value_t addrspace(10)**) #0 {
+; LV-LAVEL: L26.lver.check
+; LV: [[OFMul:%[^ ]*]] = call { i64, i1 } @llvm.umul.with.overflow.i64(i64 4, i64 [[Step:%[^ ]*]])
+; LV-NEXT: [[OFMulResult:%[^ ]*]] = extractvalue { i64, i1 } [[OFMul]], 0
+; LV-NEXT: [[OFMulOverflow:%[^ ]*]] = extractvalue { i64, i1 } [[OFMul]], 1
+; LV-NEXT: [[PosGEP:%[^ ]*]] = getelementptr i32, i32 addrspace(13)* [[Base:%[^ ]*]], i64 [[Step]]
+; LV-NEXT: [[NegGEP:%[^ ]*]] = getelementptr i32, i32 addrspace(13)* [[Base]], i64 [[NegStep:%[^ ]*]]
+; LV-NEXT: icmp ugt i32 addrspace(13)* [[NegGEP]], [[Base]]
+; LV-NEXT: icmp ult i32 addrspace(13)* [[PosGEP]], [[Base]]
+; LV-NOT: inttoptr
+; LV-NOT: ptrtoint
+top:
+ %1 = load %jl_value_t addrspace(10)*, %jl_value_t addrspace(10)** %0,
Bug#905622: julia 0.7.0~rc3 is available
Package: julia Version: 0.7.0~beta2 Severity: wishlist Control: block -1 by 905397 Debian's LLVM-6.0 needs some more patch. investigating.
Bug#900547: Bug#890806: dpkg: [INTL:zh_CN] Simplified Chinese translation update for dpkg
On Mon, Aug 06, 2018 at 10:51:46AM +0200, Guillem Jover wrote: > > Both translations conflict, could you please sort this out? The translation conflict was solved. Please pull the master branch of this repo: https://salsa.debian.org/chinese-team/dpkg https://salsa.debian.org/chinese-team/dpkg/commits/master This update was coordinated and has got approval from Boyuan.
Bug#905612: RFS: nsync/1.20.1-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "nsync" * Package name: nsync Version : 1.20.1-2 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libnsync-cpp1 - C library that exports various synchronization primitives (C++ li libnsync-dev - C library that exports various synchronization primitives (dev) libnsync1 - C library that exports various synchronization primitives (C lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nsync Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-2.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog http://debomatic-i386.debian.net/distribution#unstable/nsync/1.20.1-2/buildlog Changes since the last upload: nsync (1.20.1-2) UNRELEASED; urgency=medium * Add LDFLAG -Wl,--as-needed to strip unneeded shlibs depends. * Collect symbols patch from buildd.
Bug#881837: Re: Updating the h5py Uploaders list
control: close -1 already fixed in dc5f260e393c87886582be111a0493e4d6981f90 https://salsa.debian.org/science-team/h5py For some reason gbp-dch didn't include the commit message into dch.
Bug#905582: RFS: nsync/1.20.1-1 [ITP] -- tensorflow dependency
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "nsync", which is a tensorflow dependency. * Package name: nsync Version : 1.20.1-1 Upstream Author : google * URL : [fill in URL of upstreams web site] * License : Apache-2 Section : science It builds those binary packages: libnsync-cpp1 - C library that exports various synchronization primitives (C++ li libnsync-dev - C library that exports various synchronization primitives (dev) libnsync1 - C library that exports various synchronization primitives (C lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nsync Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nsync/nsync_1.20.1-1.dsc More information about hello can be obtained fro http://debomatic-amd64.debian.net/distribution#unstable/nsync/1.20.1-1/buildlog Changes since the last upload: nsync (1.20.1-1) unstable; urgency=low * Initial release. (Closes: #904440)
Bug#897767: closed by Mo Zhou (Bug#897767: fixed in highwayhash 0~20180209-g14dedec-5)
control: retitle -1 non-x86 symbols out of date control: severity -1 normal This non-x86 arches are not my priorities currently. It doesn't deserve another RFS bug to the mentors list, and it can be easily fixed by me when I get my Debian Developer account. On Mon, Aug 6, 2018 at 00:45 Adrian Bunk wrote: > Control: reopen -1 > > On Mon, Jul 23, 2018 at 01:54:03AM +, Debian Bug Tracking System wrote: > >... > > highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium > > . > >* Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767) > >... > > unfortunately this fixed it only for amd64, the package still FTBFS > on arm64/ppc64el/x32: > https://buildd.debian.org/status/package.php?p=highwayhash > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- Best,
Bug#904781: closing because h5py 2.8.0 has been uploaded
control: close -1 closing because 0.2.8 has been uploaded. I forgot to close this bug.
Bug#905439: su from util-linux breaks autopkgtest
control: close -1 Hi Antonio, The log is available here and the autopkgtest version used is 5.4.1~bpo9+2 http://debomatic-amd64.debian.net/distribution#unstable/h5py/2.8.0-1/autopkgtest So I think it would be fixed when the backported backage is updated. Sorry for the noise. On Sat, Aug 04, 2018 at 01:31:27PM -0300, Antonio Terceiro wrote: > Control: tag -1 + moreinfo unreproducible > > On Sat, Aug 04, 2018 at 03:11:17PM +0000, Lumin wrote: > > Package: autopkgtest > > Version: 5.4.2 > > Severity: serious > > > > the "su" command from util-linux breaks autopkgtest. The previous > > working one comes from shadow. > > > > python-h5py-dbg is already the newest version (2.8.0-1). > > python-h5py-dbg set to manually installed. > > python-h5py is already the newest version (2.8.0-1). > > python-h5py set to manually installed. > > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > (Reading database ... 13709 files and directories currently installed.) > > Removing autopkgtest-satdep (0) ... > > autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r > > 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c > > "import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c > > "import h5py; h5py.run_tests()" ; done > > autopkgtest [16:38:33]: test command1: [--- > > su: user does not exist > > autopkgtest [16:38:33]: test command1: ---] > > Unexpected error: > > Traceback (most recent call last): > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop > > command() > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command > > r = f(c, ce) > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup > > copyupdown(c, ce, True) > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown > > copyupdown_internal(ce[0], c[1:], upp) > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in > > copyupdown_internal > > copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host) > > File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in > > copyup_shareddir > > shutil.copy(tb, host) > > File "/usr/lib/python3.5/shutil.py", line 241, in copy > > copyfile(src, dst, follow_symlinks=follow_symlinks) > > File "/usr/lib/python3.5/shutil.py", line 120, in copyfile > > with open(src, 'rb') as fsrc: > > FileNotFoundError: [Errno 2] No such file or directory: > > '/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout' > > autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the > > testbed > > Are you sure you saw this with autopkgtest 5.4.2? This bug was present > 5.4.1, but explicitly fixed in 5.4.2. > > See the attached log for an attempt I just made at reproducing this. The > tests fail but autopkgtest itself works as expected. > autopkgtest [13:26:52]: version 5.4.2 > autopkgtest [13:26:52]: host lemur; command line: /usr/bin/autopkgtest > --apt-upgrade --log-file /tmp/log -B h5py -- lxc --sudo > autopkgtest-unstable-amd64 > autopkgtest: WARNING: running as root in testbed, because no normal user > could be determined > autopkgtest [13:27:04]: test bed setup > Get:1 http://deb.debian.org/debian unstable InRelease [233 kB] > Get:2 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [27.8 > kB] > Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [27.9 kB] > Get:4 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index > [27.9 kB] > Get:5 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index > [27.8 kB] > Get:6 http://deb.debian.org/debian unstable/non-free Sources > 2018-08-03-2013.11.pdiff [1,306 B] > Get:7 http://deb.debian.org/debian unstable/non-free Sources > 2018-08-04-0814.44.pdiff [665 B] > Get:8 http://deb.debian.org/debian unstable/main Sources > 2018-08-02-1416.04.pdiff [5,521 B] > Get:7 http://deb.debian.org/debian unstable/non-free Sources > 2018-08-04-0814.44.pdiff [665 B] > Get:9 http://deb.debian.org/debian unstable/main Sources > 2018-08-02-2015.39.pdiff [10.3 kB] > Get:10 http://deb.debian.org/debian unstable/main Sources > 2018-08-03-0208.52.pdiff [3,145 B] > Get:11 http://deb.debian.org/debian unstable/main Sources > 2018-08-03-0811.08.p
Bug#905439: su from util-linux breaks autopkgtest
Package: autopkgtest Version: 5.4.2 Severity: serious the "su" command from util-linux breaks autopkgtest. The previous working one comes from shadow. python-h5py-dbg is already the newest version (2.8.0-1). python-h5py-dbg set to manually installed. python-h5py is already the newest version (2.8.0-1). python-h5py set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. (Reading database ... 13709 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [16:38:33]: test command1: set -e ; for py in $(pyversions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import h5py; h5py.run_tests()" ; echo "Testing with $py-dbg:" ; $py-dbg -c "import h5py; h5py.run_tests()" ; done autopkgtest [16:38:33]: test command1: [--- su: user does not exist autopkgtest [16:38:33]: test command1: ---] Unexpected error: Traceback (most recent call last): File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 717, in mainloop command() File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 646, in command r = f(c, ce) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 584, in cmd_copyup copyupdown(c, ce, True) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 469, in copyupdown copyupdown_internal(ce[0], c[1:], upp) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 494, in copyupdown_internal copyup_shareddir(sd[0], sd[1], dirsp, downtmp_host) File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 408, in copyup_shareddir shutil.copy(tb, host) File "/usr/lib/python3.5/shutil.py", line 241, in copy copyfile(src, dst, follow_symlinks=follow_symlinks) File "/usr/lib/python3.5/shutil.py", line 120, in copyfile with open(src, 'rb') as fsrc: FileNotFoundError: [Errno 2] No such file or directory: '/var/run/schroot/mount/unstable-amd64-debomatic-98e10886-4014-46ea-a35e-37ffe71bdcf3/tmp/autopkgtest.mZ5fp7/command1-stdout' autopkgtest [16:38:34]: ERROR: testbed failure: unexpected eof from the testbed
Bug#905397: Unable to build Julia 0.7.0~rc2 due to illegal inttoptr
Package: llvm-6.0-dev Version: 1:6.0.1-2 Severity: important X-Debbugs-CC: pkg-julia-de...@lists.alioth.debian.org When trying to build Julia 0.7.0~rc2 on expeirmental, I encountered an error from llvm, as shown in the bottom part of this email. I haven't ingestigated into this problem but maybe debian's llvm needs this patch? https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-D49832-SCEVPred.patch Julia 0.7.0~rc2 is available here g...@salsa.debian.org:julia-team/julia.git in the "experimental" branch. ``` Statistics ─ 0.335774 seconds Stdlibs total ── 66.031648 seconds Sysimage built. Summary: Total ─── 90.179929 seconds Base: ─── 24.146837 seconds 26.7763% Stdlibs: 66.031648 seconds 73.2221% make[3]: Leaving directory '/home/lumin/packages/julia.pkg/julia' make[3]: Entering directory '/home/lumin/packages/julia.pkg/julia' cd /home/lumin/packages/julia.pkg/julia/base && if ! /home/lumin/packages/julia.pkg/julia/usr/bin/julia -O3 -C "x86-64" --output-o /home/lumin/packages/julia.pkg/julia/usr/lib/x86_64-linux-gnu/julia/sys-o.a.tmp --startup-file=no --warn-overwrite=yes --sysimage /home/lumin/packages/julia.pkg/julia/usr/lib/x86_64-linux-gnu/julia/sys.ji /home/lumin/packages/julia.pkg/julia/contrib/generate_precompile.jl /home/lumin/packages/julia.pkg/julia/usr/lib/x86_64-linux-gnu/julia/sys.ji; then echo '*** This error is usually fixed by running `make clean`. If the error persists, try `make cleanall`. ***'; false; fi Generating precompile statements... 751 generated in 30.780778 seconds Illegal inttoptr %scevgep9 = ptrtoint i32 addrspace(13)* %scevgep to i64 Illegal inttoptr %scevgep1011 = ptrtoint i32 addrspace(13)* %scevgep10 to i64 signal (6): Aborted in expression starting at no file:0 gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) runOnFunction at ./src/./src/llvm-gc-invariant-verifier.cpp:178 _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at /usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1 (unknown line) _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at /usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1 (unknown line) _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at /usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1 (unknown line) operator() at ./src/./src/jitlayers.cpp:1182 [inlined] jl_dump_native at ./src/./src/jitlayers.cpp:1191 jl_write_compiler_output at ./src/./src/precompile.c:84 jl_atexit_hook at ./src/./src/init.c:233 main at ./ui/./ui/repl.c:234 __libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) _start at /home/lumin/packages/julia.pkg/julia/usr/bin/julia (unknown line) Allocations: 56990078 (Pool: 56980033; Big: 10045); GC: 124 Aborted *** This error is usually fixed by running `make clean`. If the error persists, try `make cleanall`. *** make[3]: *** [Makefile:216: /home/lumin/packages/julia.pkg/julia/usr/lib/x86_64-linux-gnu/julia/sys-o.a] Error 1 make[3]: Leaving directory '/home/lumin/packages/julia.pkg/julia' make[2]: *** [Makefile:78: julia-sysimg-release] Error 2 make[2]: Leaving directory '/home/lumin/packages/julia.pkg/julia' dh_auto_build: make -j4 "INSTALL=install --strip-program=true" prefix=/usr sysconfdir=/etc DESTDIR=debian/tmp/ LLVM_CONFIG=/usr/bin/llvm-config-6.0 LLVM_VER=6.0 MULTIARCH=x86_64-linux-gnu MULTIARCH_INSTALL=1 NO_GIT=1 "TAGGED_RELEASE_BANNER=Debian ⛬ julia/0.7.0~rc2-1" USE_BLAS64=0 USE_LLVM_SHLIB=1 USE_SYSTEM_BLAS=1 USE_SYSTEM_CURL=1 USE_SYSTEM_DSFMT=1 USE_SYSTEM_FFTW=1 USE_SYSTEM_GMP=1 USE_SYSTEM_LAPACK=1 USE_SYSTEM_LIBGIT2=1 USE_SYSTEM_LIBSSH2=1 USE_SYSTEM_LIBUNWIND=1 USE_SYSTEM_LIBUV=0 USE_SYSTEM_LLVM=1 USE_SYSTEM_MBEDTLS=1 USE_SYSTEM_MPFR=1 USE_SYSTEM_OPENSPECFUN=1 USE_SYSTEM_PATCHELF=1 USE_SYSTEM_PCRE=1 USE_SYSTEM_SUITESPARSE=1 USE_SYSTEM_UTF8PROC=1 VERBOSE=1 MARCH=x86-64 USE_SYSTEM_OPENLIBM=1 USE_SYSTEM_LIBM=0 LIBBLAS=-lopenblas LIBBLASNAME=libopenblas LIBLAPACK=-lopenblas LIBLAPACKNAME=libopenblas returned exit code 2 make[1]: *** [debian/rules:109: override_dh_auto_build] Error 2 make[1]: Leaving directory '/home/lumin/packages/julia.pkg/julia' make: *** [debian/rules:106: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 debuild: fatal error at line 1152: dpkg-buildpackage -rfakeroot -us -uc -ui -i -j4 failed ```
Bug#905101: not working with python3
Package: pius Version: 2.2.6-1 Severity: serious Justification: totally unusable with python3. ~ ❯❯❯ pius -A -s -r ~/.gnupg/pubring.kbx -m Welcome to PIUS, the PGP Individual UID Signer. Traceback (most recent call last): File "/usr/bin/pius", line 328, in main() File "/usr/bin/pius", line 261, in main options.mail_host File "/usr/lib/python3/dist-packages/libpius/signer.py", line 88, in __init__ self.gpg2 = self._is_gpg2() File "/usr/lib/python3/dist-packages/libpius/signer.py", line 120, in _is_gpg2 m = re.match(r'^gpg \(GnuPG.*\) ([0-9\.]+)$', line) File "/usr/lib/python3.6/re.py", line 172, in match return _compile(pattern, flags).match(string) TypeError: cannot use a string pattern on a bytes-like object https://github.com/jaymzh/pius/issues/98
Bug#905053: RFS: trojan/1.5.1-1 [ITP]
Hi GreaterFire, Thank you for the package. I'm not sponsoring this package but I have some comments about it. You can feel free to omit the comments tagged "recommended". 1. Why is dh_auto_test noopped? The following tests FAILED: 1 - LinuxSmokeTest-basic (Failed) As the software upstream, you should try to fix the bug instead of ignoring it. 2. [Recommended] It would be better if there are Vcs-Browser and Vcs-Git fields in the control file. 3. [Recommended] testsuite-autopkgtest-missing. A set of sensible test scripts would speed up its migration into testing. http://packaging.ubuntu.com/html/auto-pkg-test.html 4. package-does-not-install-examples . There are several example files under the source tree. Please install them so that the user can find them after installation. 1. create a file debian/examples 2. put this line in the file ``` examples/* ``` Well, the copyright file looks good to me. Please fix the issues mentioned above, and do lintian check if you think it's ready for the next round of review. ``` lintian -EviI --pedantic xxx.changes ``` Feel free to ask if you encounter problem.
Bug#904320: ease backporting
Hi Daniel, > How about only generating the files when creating the source package, > rather than during every build. that way, you would need to run it only > before uploading the package, once; and none of the buildds would run it > again which would also make the package a bit more resiliant. Sorry but no, I won't keep any automatically-generated files in the source tarball. And the file generator control.py generates different files for amd64 and i386. However, if you are willing to port it back to stretch, I can port control.py to python3.5 .
Bug#904434: intel-mkl: FTBFS in C locale
control: tags -1 +pending fixed in master branch.
Bug#904440: ITP: nsync -- C library that exports various synchronization primitives, such as mutexes [TF deps]
Package: wnpp Severity: wishlist Owner: lumin * Package name: nsync Version : 1.20.0 Upstream Author : google * URL : https://github.com/google/nsync * License : Apache-2.0 Programming Lang: C Description : C library that exports various synchronization primitives, such as mutexes tensorflow dependency
Bug#904319: FTBFS when building binary-packages only
Thanks for the full log, very helpful! I can reproduce the failure with LC_ALL=POSIX python3 ... and it could be avoided by LC_ALL=C.UTF-8 python3 ... On Mon, Jul 23, 2018 at 02:43:41PM +0200, Santiago Vila wrote: > On Mon, Jul 23, 2018 at 12:16:45PM +0000, Lumin wrote: > > > Thanks for the report, but could you please provider a more verbose > > failure report? > > Sure. I've put the full build log here: > > https://people.debian.org/~sanvila/build-logs/intel-mkl/ > > This was a binary-indep only build, i.e. "dpkg-buildpackage -A". > > Assuming "dpkg-buildpackage -A" is not the issue here, you would get full > build logs here as well: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/intel-mkl.html > > but only when the page finally exists. > > > And could you please test this patch: > > > > LC_ALL=C.UTF-8 python3 debian/control.py > > Sorry, I can't test modified packages easily in my autobuilder setup. > > You should be able to reproduce this using either sbuild or pbuilder. > By looking at the proposed patch I bet that this could be reproduced > with a simple chroot as well, setting LC_ALL=C before dpkg-buildpackage, > but I don't really know. > > Thanks.
Bug#904319: FTBFS when building binary-packages only
Hi Santiago, Thanks for the report, but could you please provider a more verbose failure report? And could you please test this patch: LC_ALL=C.UTF-8 python3 debian/control.py ``` diff --git a/debian/rules b/debian/rules index 212c9aa..8d21adc 100755 --- a/debian/rules +++ b/debian/rules @@ -39,7 +39,7 @@ autogen: extract-rpms $(AUTOGEN_FILES) chmod +x debian/libmkl-dev.postinst debian/libmkl-dev.prerm debian/libmkl-dev.config override_dh_auto_configure: autogen - python3 debian/control.py # Generate install files and lintian overrides + LC_ALL=C.UTF-8 python3 debian/control.py # Generate install files and lintian overrides # deal with embedded libjs-jquery $(RM) opt/intel/documentation_2018/ja/mkl/ps2018/resources/jquery-1.11.1.min.js ```
Bug#901201: ITP: python-plac -- Smartest command line arguments parser in the world [spaCy deps]
control: retitle -1 RFP: python-plac -- Smartest command line arguments parser in the world [spaCy deps] control: noowner -1 In most cases installing spaCy with pip is enough. spaCy depends on yet another specific machine learning library "thinc" which I think I don't have enough energy to take care of in long run. package available here: https://salsa.debian.org/python-team/modules/python-plac
Bug#900977: ITP: python-murmurhash -- Cython bindings for MurmurHash2 [spaCy deps]
control: retitle -1 RFP: python-murmurhash -- Cython bindings for MurmurHash2 [spaCy deps] control: noowner -1 In most cases installing spaCy with pip is enough. spaCy depends on yet another specific machine learning library "thinc" which I think I don't have enough energy to take care of in long run. package available here: https://salsa.debian.org/python-team/modules/python-murmurhash
Bug#900945: ITP: python-preshed -- Cython Hash Table for Pre-Hashed Keys [spaCy dependency]
control: retitle -1 RFP: python-preshed -- Cython Hash Table for Pre-Hashed Keys [spaCy dependency] control: noowner -1 In most cases installing spaCy with pip is enough. spaCy depends on yet another specific machine learning library "thinc" which I think I don't have enough energy to take care of in long run. package available here https://salsa.debian.org/python-team/modules/python-preshed
Bug#901231: ITP: python-thinc -- Practical Machine Learning for NLP in Python [spaCy deps]
control: retitle -1 RFP: python-thinc -- Practical Machine Learning for NLP in Python [spaCy deps] control: noowner -1 In most cases installing spaCy with pip is enough. spaCy depends on yet another specific machine learning library "thinc" which I think I don't have enough energy to take care of in long run. package available here https://salsa.debian.org/science-team/python-thinc
Bug#891074: ITP: you-get/0.4.1025 -- command-line utility to download media contents (videos, audios, images) from the Web
control: retitle -1 RFP: you-get/0.4.1025 -- command-line utility to download media contents (videos, audios, images) from the Web control: noowner -1 initial packaging is available here https://salsa.debian.org/lumin-guest/you-get but anyone who wants to download video from internet must be able to pip install you-get and pip doesn't lag behind upstream.
Bug#900941: ITP: python-cymem -- Cython Memory Helper [SpaCy dependency]
control: retitle -1 RFP: python-cymem -- Cython Memory Helper [SpaCy dependency] control: noowner -1 In most cases installing spaCy with pip is enough. spaCy depends on yet another specific machine learning library "thinc" which I think I don't have enough energy to take care of in long run. Packaging avaiable here https://salsa.debian.org/python-team/modules/python-cymem
Bug#904229: RFS: highwayhash/0~20180209-g14dedec-5 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "highwayhash" * Package name: highwayhash Version : 0~20180209-g14dedec-5 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash (development) libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/highwayhash Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-5.dsc More information about hello can be obtained from https://www.example.com. http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-5/autopkgtest Changes since the last upload: highwayhash (0~20180209-g14dedec-5) unstable; urgency=medium * Refresh symbols to avoid FTBFS with GCC-8 (Closes: #897767) * Bump Standards-Version to 4.1.5 (no change).
Bug#904140: Add julia interpreter
Package: lintian Version: 2.5.93 Severity: wishlist X-Debbugs-CC: Debian Julia Team Julia is a scripting language with JIT compilation. I think lintian should recognize it as one of the available interpreters in Debian. W: julia-common: unusual-interpreter usr/share/julia/stdlib/v0.7/Pkg/bin/generate.jl #!/usr/bin/julia
Bug#903879: Add openblas 0.3.1 dgesvd regression test to julia
Package: julia Version: 0.6.4-2+b1 Severity: important Owner: ! https://github.com/JuliaLang/julia/pull/28129 This patch is for julia 0.7.X . Maybe I should backport this test to 0.6.X .
Bug#903695: apt: [INTL:zh_CN] Simplified Chinese translation update (for apt 1.7.x)
control: tags -1 +confirmed I'm the last APT translator. Boyuan's patch LGTM. signature.asc Description: PGP signature
Bug#903659: OpenBLAS 0.3.1 gives incorrect SVD result
Package: libopenblas-base Version: 0.3.1+ds-1 Severity: serious https://github.com/JuliaLang/julia/pull/28002 https://github.com/JuliaLang/julia/issues/27960 https://github.com/xianyi/OpenBLAS/issues/1666
Bug#894629: dropping ITP
control: retitle -1 RFP: spacy/2.0.10 -- Industrial-strength Natural Language Processing (NLP) with Python and Cython control: noowner -1 lack of time.
Bug#889951: dropping ITP
control: retitle -1 RFP: nanopb/0.3.9 -- Protocol Buffers with small code size control: noowner lack of time.
Bug#889950: drop ITP
control: retitle -1 RFP: gloo/0.5.0 -- Collective communications library for machine learning control: noowner -1 lack of time.
Bug#894628: drop ITP
control: retitle -1 RFP: cupy/2.5.0 -- NumPy-like API accelerated with CUDA control: noowner -1 CUDA's GCC/LLVM support is always lagging behind the GCC/LLVM upstreams. That makes the maintenance work of CUDA application always annoying. I'm dropping this ITP. Afterall the user can install cupy simply with pip.
Bug#825970: pypy: Please package pypy3 as well now
Hi Stefano, Python2 is dying. Is there any reason so that pypy3 shouldn't be compiled and uploaded? If you lack time and need help, please just ask.
Bug#903548: RM: julia -- RoM; remove mips64el architecture
Package: ftp.debian.org Severity: normal We want julia 0.6.4 to migrate to testing: julia | 0.6.4-1 | unstable | source, amd64, arm64, armhf, i386, ppc64el however it is blocked by the mips64el architecture, because julia 0.6.4 doesn't build on mips64el currently, different from 0.4.7 : julia | 0.4.7-7 | unstable | source julia | 0.4.7-7 | unstable-debug | source julia | 0.4.7-7+b3| unstable | mips64el Please remove julia 0.4.7, and the corresponding mips64el package. signature.asc Description: PGP signature
Bug#873408: lowering severity
Control: severity -1 important julia_0.6.3-5 was just uploaded to unstable, it depends on llvm-4.0 .
Bug#903372: please upload 0.27 to unstable
Package: libgit2-dev Version: 0.26.0+dfsg.1-1.2 Severity: wishlist Dear libgit2 maintainer, We wish to upload Julia to unstable. It depends on libgit2 >= 0.27, which ships mbedtls support so that https:// is supported. Could you please upload libgit2 to unstable?
Bug#903269: sbuild-adduser is missing
Package: sbuild Version: 0.77.0-1 Severity: imporant ~ ❯❯❯ sbuild User lumin is not currently an effective member of group sbuild. Please run: sudo sbuild-adduser lumin And then either log out and log in again or use `newgrp sbuild` to gain sbuild group privileges ~ ❯❯❯ sudo sbuild-adduser lumin sudo: sbuild-adduser: command not found ~ ❯❯❯ apt-file search sbuild-adduser sbuild: /usr/sbin/sbuild-adduser sbuild: /usr/share/man/man8/sbuild-adduser.8.gz ~ ❯❯❯ stat /usr/sbin/sbuild-adduser stat: cannot stat '/usr/sbin/sbuild-adduser': No such file or directory ~ ❯❯❯ dpkg -L sbuild | grep adduser /usr/share/man/man8/sbuild-adduser.8.gz ~ ❯❯❯ apt list sbuild Listing... Done sbuild/unstable,unstable,unstable,unstable,now 0.77.0-1 all [installed] The bug is introduced by this commit: https://salsa.debian.org/debian/sbuild/commit/9f08bb7ec57574fd299a23b92253ddee4be63493
Bug#902926: lintian suggests inexistent libjs-normalize.css package
Package: lintian Version: 2.5.91 Severity: normal Lintian reports error like this E: julia-doc: privacy-breach-uses-embedded-file usr/share/doc/julia/html/en/devdocs/sysimg.html You may use the libjs-normalize.css package. (https://cdnjs.cloudflare.com/ajax/libs/normalize/4.2.0/normalize.min.css) but there isn't any libjs-normalize.css file in the archive. However, the corresponding file can be found in the node-normalize.css package.
Bug#902914: Arpack not working correctly
Package: libarpack2
Version: 3.6.1-1
Severity: Important
Hi arpack maintainer,
The present libarpack2 has a problem so that Julia 0.6.3 cannot
pass the tests as expected. I tried to dig out the cause but found nothing.
When we build arpack 3.3.0 with this makefile
https://github.com/JuliaLang/julia/blob/v0.6.3/deps/arpack.mk
everything is working.
Here are several ralted reports:
https://bugs.archlinux.org/task/58221
https://github.com/opencollab/arpack-ng/issues/30
https://github.com/JuliaLang/julia/issues/26830
Julia 0.6.3's test failure with libarpack2.
julia> Base.runtests(["linalg/arnoldi"])
Test (Worker) | Time (s) | GC (s) | GC % | Alloc (MB) | RSS (MB)
elty = Float64: Error During Test
Got an exception of type Base.LinAlg.ARPACKException outside of a @test
Base.LinAlg.ARPACKException("unexpected behavior")
Stacktrace:
[1] aupd_wrapper(::Type{T} where T,
::Base.LinAlg.#matvecA!#114{SparseMatrixCSC{Float64,Int64}},
::Base.LinAlg.##108#115, ::Base.LinAlg.##109#116, ::Int64, ::Bool, ::Bool,
::String, ::Int64, ::Int32, ::String, ::Float64, ::Int64, ::Int64,
::Array{Float64,1}) at ./linalg/arpack.jl:63
[2] #_eigs#107(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void,
::Array{Float64,1}, ::Bool, ::Base.LinAlg.#_eigs,
::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at
./linalg/arnoldi.jl:285
[3] (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs,
::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
[4] #eigs#100 at ./linalg/arnoldi.jl:91 [inlined]
[5] (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs,
::SparseMatrixCSC{Float64,Int64}, ::UniformScaling{Int64}) at ./:0
[6] #eigs#99 at ./linalg/arnoldi.jl:90 [inlined]
[7] (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs,
::SparseMatrixCSC{Float64,Int64}) at ./:0
[8] macro expansion at /usr/share/julia/test/linalg/arnoldi.jl:33 [inlined]
[9] macro expansion at ./test.jl:921 [inlined]
[10] macro expansion at /usr/share/julia/test/linalg/arnoldi.jl:17 [inlined]
[11] macro expansion at ./test.jl:860 [inlined]
[12] anonymous at ./:?
[13] macro expansion at /usr/share/julia/test/testdefs.jl:18 [inlined]
[14] macro expansion at ./test.jl:860 [inlined]
[15] macro expansion at ./util.jl:378 [inlined]
[16] macro expansion at /usr/share/julia/test/testdefs.jl:17 [inlined]
[17] anonymous at ./:?
[18] runtests(::String, ::Bool) at /usr/share/julia/test/testdefs.jl:21
[19] (::Base.Distributed.##135#136{#runtests,Tuple{String},Array{Any,1}})()
at ./distributed/remotecall.jl:319
[20]
run_work_thunk(::Base.Distributed.##135#136{#runtests,Tuple{String},Array{Any,1}},
::Bool) at ./distributed/process_messages.jl:56
[21] #remotecall_fetch#140(::Array{Any,1}, ::Function, ::Function,
::Base.Distributed.LocalProcess, ::String, ::Vararg{String,N} where N) at
./distributed/remotecall.jl:344
[22] remotecall_fetch(::Function, ::Base.Distributed.LocalProcess, ::String,
::Vararg{String,N} where N) at ./distributed/remotecall.jl:344
[23] macro expansion at /usr/share/julia/test/runtests.jl:57 [inlined]
[24] (::##44#50)() at ./task.jl:335
elty = Complex{Float64}: Error During Test
Got an exception of type Base.LinAlg.ARPACKException outside of a @test
Base.LinAlg.ARPACKException("unexpected behavior")
Stacktrace:
[1] aupd_wrapper(::Type{T} where T,
::Base.LinAlg.#matvecA!#114{SparseMatrixCSC{Complex{Float64},Int64}},
::Base.LinAlg.##108#115, ::Base.LinAlg.##109#116, ::Int64, ::Bool, ::Bool,
::String, ::Int64, ::Int32, ::String, ::Float64, ::Int64, ::Int64,
::Array{Complex{Float64},1}) at ./linalg/arpack.jl:63
[2] #_eigs#107(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void,
::Array{Complex{Float64},1}, ::Bool, ::Base.LinAlg.#_eigs,
::SparseMatrixCSC{Complex{Float64},Int64}, ::UniformScaling{Int64}) at
./linalg/arnoldi.jl:285
[3] (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs,
::SparseMatrixCSC{Complex{Float64},Int64}, ::UniformScaling{Int64}) at
./:0
[4] #eigs#100 at ./linalg/arnoldi.jl:91 [inlined]
[5] (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs,
::SparseMatrixCSC{Complex{Float64},Int64}, ::UniformScaling{Int64}) at
./:0
[6] #eigs#99 at ./linalg/arnoldi.jl:90 [inlined]
[7] (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs,
::SparseMatrixCSC{Complex{Float64},Int64}) at ./:0
[8] macro expansion at /usr/share/julia/test/linalg/arnoldi.jl:33 [inlined]
[9] macro expansion at ./test.jl:921 [inlined]
[10] macro expansion at /usr/share/julia/test/linalg/arnoldi.jl:17 [inlined]
[11] macro expansion at ./test.jl:860 [inlined]
[12] anonymous at ./:?
[13] macro expansion at /usr/share/julia/test/testdefs.jl:18 [inlined]
[14] macro expansion at ./test.jl:860 [inlined]
[15] macro expansion at ./util.jl:378 [inlined]
[16] macro expansion at /usr/share/julia/test/testdefs.jl:17 [inlined]
[17] anonymous at ./:?
[1
Bug#902902: [utf8proc] string normalization bug
Package: libutf8proc2
Version: 2.1.0-1
Severity: Important
2.1.0-1 causes julia 0.6.3 test failure.
│
│ ~/p/j/j/test ❯❯❯ /usr/bin/julia ./runtests.jl unicode/utf8proc
│ Test (Worker)| Time (s) | GC (s) | GC % | Alloc (MB) | RSS (MB)
│ string normalization: Test Failed
│ Expression: normalize_string("ṛ̇", :NFC) == "ṛ̇"
│Evaluated: "Ṥ" == "ṛ̇"
│ Stacktrace:
│ [1] macro expansion at
/home/lumin/packages/julia.pkg/julia/test/unicode/utf8proc.jl:23 [inlined]
│ [2] macro expansion at ./test.jl:860 [inlined]
│ [3] anonymous at ./:?
│ Worker 1 failed running test unicode/utf8proc:
│ Some tests did not pass: 768 passed, 1 failed, 0 errored, 0
broken.unicode/utf8proc: Test Failed
│ Expression: normalize_string("ṛ̇", :NFC) == "ṛ̇"
│Evaluated: "Ṥ" == "ṛ̇"
│ Stacktrace:
│ [1] record(::Base.Test.DefaultTestSet, ::Base.Test.Fail) at ./test.jl:568
│ [2] (::##40#46)() at
/home/lumin/packages/julia.pkg/julia/test/runtests.jl:160
│ [3] cd(::##40#46, ::String) at ./file.jl:70
│
│ Test Summary: | Pass Fail Total
│ Overall | 768 1769
│ unicode/utf8proc | 768 1769
│ FAILURE
│ Error in testset unicode/utf8proc:
│ Test Failed
│ Expression: normalize_string("ṛ̇", :NFC) == "ṛ̇"
│Evaluated: "Ṥ" == "ṛ̇"
│ ERROR: LoadError: Test run finished with errors
│ while loading /home/lumin/packages/julia.pkg/julia/test/runtests.jl, in
expression starting on line 29
│
After manually replacing the .so file with 2.1.1
│
│~/p/j/j/test ❯❯❯ /usr/bin/julia ./runtests.jl unicode/utf8proc
│Test (Worker)| Time (s) | GC (s) | GC % | Alloc (MB) | RSS (MB)
│unicode/utf8proc (1) |2.12 | 0.08 | 3.9 | 59.13 | 236.96
│
│Test Summary: | Pass Total
│ Overall | 769769
│SUCCESS
│
Reference fix:
upload 2.1.1
Bug#902412: RFS: sodalite/0.14.2-1 [ITP]
Hi Heiko Nickerl, > I am looking for a sponsor for my package "sodalite". Thank you for this package. I'm not sponsoring this package, but I have some comments: 1. debian/copyright: OK 2. postinst: Printing something unecessary to screen during postinst looks unusual. I believe the messages would be better to appear in Description. See: Policy Section 3.9 https://www.debian.org/doc/debian-policy/#maintainer-scripts "The package installation scripts should avoid producing output which is unnecessary for the user to see and should rely on dpkg to stave off boredom on the part of a user installing many packages." Others may be good.
Bug#901958: RFS: lsmount/0.2.2-1 [ITP] -- output /proc/mounts formatted
Hi Andreas Schwarz, > I am looking for a sponsor for my package "lsmount" Thank you for this package. I'm not sponsoring it but here are some comments: 1. debian/copyright: OK 2. debian/rules: MINOR The debhelper compat level is set to 11. That means --parallel is default. So you don't have to specify it. See: debhelper(7), seciton "COMPATIBILITY LEVELS" The rest files look good to me.
Bug#902577: RFS: highwayhash/0~20180209-g14dedec-4
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "highwayhash" * Package name: highwayhash Version : 0~20180209-g14dedec-4 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : science It builds those binary packages: libhighwayhash-dev - Fast strong hash functions: SipHash/HighwayHash (development) libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/highwayhash Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-4.dsc More information about hello can be obtained from http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-4/buildlog Changes since the last upload: highwayhash (0~20180209-g14dedec-4) unstable; urgency=medium * Depending on build-essential to really fix autopkgtest failure. * Add watch file to monitor upstream git HEAD. * Don't override debian-watch-file-is-missing, already fixed. * Bump Standards-Version to 4.1.4 (no change).
Bug#902480: [skimage] autopkgtest failure
Package: python-skimage-doc
Version: 0.14.0-1
Severity: normal
Justification: Severity is raised from wishlist to normal because autopkgtest
affects migration now.
http://debomatic-amd64.debian.net/distribution#unstable/skimage/0.14.0-1/autopkgtest
Setting up xvfb (2:1.20.0-2) ...
Setting up autopkgtest-satdep (0) ...
Processing triggers for libc-bin (2.27-3) ...
(Reading database ... 18444 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [05:00:55]: test python3: [---
=== python3.6 ===
/tmp/autopkgtest.hvdeQq/build.6xl/src/debian/tests/python3: 18:
/tmp/autopkgtest.hvdeQq/build.6xl/src/debian/tests/python3: PYTHONPATH:
parameter not set
autopkgtest [05:00:55]: test python3: ---]
python3 FAIL non-zero exit status 2
autopkgtest [05:00:55]: test python3: - - - - - - - - - - results - - - - - -
- - - -
autopkgtest [05:00:55]: test python3: - - - - - - - - - - stderr - - - - - - -
- - -
/tmp/autopkgtest.hvdeQq/build.6xl/src/debian/tests/python3: 18:
/tmp/autopkgtest.hvdeQq/build.6xl/src/debian/tests/python3: PYTHONPATH:
parameter not set
autopkgtest [05:00:55]: summary
python2 FAIL non-zero exit status 2
python3 FAIL non-zero exit status 2
Reference fix:
```
diff --git a/debian/tests/python2 b/debian/tests/python2
index 47ba7d8d..d5e0dbe7 100755
--- a/debian/tests/python2
+++ b/debian/tests/python2
@@ -1,5 +1,5 @@
#!/bin/sh
-set -efu
+set -efux
pys="$(pyversions -rv 2>/dev/null)"
pkgbuild=${pkgbuild:-no}
@@ -10,11 +10,12 @@ srcdir=$PWD
for py in $pys; do
echo "=== python$py ==="
if [ "$pkgbuild" = "yes" ]; then
-export PYTHONPATH="$srcdir/debian/tmp/usr/lib/python$py/dist-packages"
+module="$srcdir/debian/tmp/usr/lib/python$py/dist-packages/skimage"
cd "$srcdir/build/"
else
+module="/usr/lib/python$py/dist-packages/skimage"
cd "$ADTTMP"
fi
-xvfb-run -a python$py /usr/bin/pytest -s -v -k "$keyword" skimage 2>&1
+xvfb-run -a python$py /usr/bin/pytest -s -v -k "$keyword" $module 2>&1
done
diff --git a/debian/tests/python3 b/debian/tests/python3
index abc21bf6..6625bc94 100755
--- a/debian/tests/python3
+++ b/debian/tests/python3
@@ -9,11 +9,12 @@ srcdir=$PWD
for py in $pys; do
echo "=== python$py ==="
if [ "$pkgbuild" = "yes" ]; then
-export PYTHONPATH="$srcdir/debian/tmp/usr/lib/python3/dist-packages"
+module="$srcdir/debian/tmp/usr/lib/python3/dist-packages/skimage"
cd "$srcdir/build/"
else
+module="/usr/lib/python3/dist-packages/skimage"
cd "$ADTTMP"
fi
-xvfb-run -apython$py /usr/bin/pytest-3 -s -v skimage 2>&1
+xvfb-run -apython$py /usr/bin/pytest-3 -s -v $module 2>&1
done
```
Bug#902479: [skimage] python-skimage-doc: 35 lintian Errors
Package: python-skimage-doc
Version: 0.14.0-1
Severity: normal
E: python-skimage-doc: privacy-breach-uses-embedded-file
usr/share/doc/python-skimage-doc/html/cell_profiler.html You may use the
libjs-mathjax package.
(https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/mathjax.js?config=tex-ams-mml_htmlormml)
Patch
```
diff --git a/debian/rules b/debian/rules
index 82c3ed98..784c3e19 100755
--- a/debian/rules
+++ b/debian/rules
@@ -83,6 +83,9 @@ ifneq (,$(findstring -a,$(DH_INTERNAL_OPTIONS)))
: # no documentation in -a -- surprised that sphinxdoc doesn't know that
else
dh_sphinxdoc -ppython-skimage-doc
+ find debian -type f -exec sed -i -e \
+
's@https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js@file:///usr/share/javascript/mathjax/MathJax.js@g'
\
+ '{}' +
endif
endif
```
And the doc package should depend on libjs-mathjax.
Bug#902478: [skimage] broken documentation package
Package: python-skimage-doc Version: 0.14.0-1 Severity: normal from 0.14.0-1 debian/rules: ``` @@ -15,0 +16,2 @@ skimage (0.14.0-1) unstable; urgency=medium cd doc; test -d build/html || $(MAKE) html cd doc; test -d build/html || $(MAKE) html PYTHON=python3 ``` This actually didn't work properly, because sphinx (python3) failed to grab python3 package from python2 import path. ``` export PYTHONPATH=$(PKG_TMP)/usr/lib/python$(PYVER)/dist-packages; ``` Consequence: API documents are missing from python-skimage-doc. reference solution: export PYTHONPATH=$(PKG_TMP)/usr/lib/python3/dist-packages; reference buildlog: : # Build Documentation export PYTHONPATH=/<>/debian/tmp/usr/lib/python2.7/dist-packages; \ cd doc; test -d build/html || /usr/bin/make html PYTHON=python3 make[2]: Entering directory '/<>/doc' python3 tools/build_modref_templates.py *WARNING* API documentation not generated: Can not import skimage Build API docs...done. Copying release notes python /usr/bin/sphinx-build -b html -d build/doctrees -j 1 source build/html Running Sphinx v1.7.5 making output directory... loading pickled environment... not yet created http://debomatic-amd64.debian.net/distribution#unstable/skimage/0.14.0-1/buildlog
Bug#901377: skimage: FTBFS and Debci failure with NumPy 1.14
X-Debbugs-CC: gin...@debian.org, stef...@berkeley.edu, deb...@onerussian.com control: owner -1 ! I'm working on this. It would take days for me to finish it due to my final terms... But I think it doesn't matter because we still have a month until AUTORM. https://salsa.debian.org/lumin-guest/skimage/commits/master
