Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland
Control: close -1 I merged your files and uploaded to unstable. The source name is hyprlang directly without the lib prefix. https://salsa.debian.org/debian/hyprlang On 4/18/24 03:16, Alan M Varghese wrote: Hello Mo, Thank you for granting me access. I believe this would require me to force push from local repo? Wouldn't this result in the loss of your own commit history? Or we could merge the two from a different branch. But that feels like too much work :p If you feel it is worth it to push from my repo, please feel free to do so. Or, I am also okay with it if you just keep what you have done there and we can iterate on top of it without pushing from my repo (from a cursory look, we just need to bring in latest upstream version, add a watch file etc). PS: Are you active on IRC? I am usually active daytime, Indian Standard Time. What are your preferred timings?
Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland
Control: close -1
Sponsored directly from git.
On 4/17/24 11:19, Mo Zhou wrote:
I have forked your repo to here:
https://salsa.debian.org/debian/hyprland-protocols
Will sponsor later when I get my other computer.
On 4/15/24 12:19, Alan M Varghese wrote:
Control: tags -1 - moreinfo
Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not
<< 0.2
as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends}
(which
will be emoty anyway).
Done and done.
Alan M Varghese (NyxTrail)
Bug#1066871: Fwd: Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland
On 4/19/24 12:24, Alan M Varghese wrote: If you feel it is worth it to push from my repo, please feel free to do so. Or, I am also okay with it if you just keep what you have done there and we can iterate on top of it without pushing from my repo (from a cursory look, we just need to bring in latest upstream version, add a watch file etc). In that case we can simply add these several new files and commit them, not pulling the whole git tree. PS: Are you active on IRC? I am usually active daytime, Indian Standard Time. What are your preferred timings? My only contact point for debian work is email and I do not use IRC at all. For email, timing does not matter. On 17/04/24 20:39, Mo Zhou wrote: Hi Alan, I granted you with the maintainer access to this repo: https://salsa.debian.org/debian/hyprlang This package has cleared the NEW queue a while ago: https://tracker.debian.org/pkg/hyprlang Could you please push your changes from personal repo to the above repo? I can also do it for you if you don't mind not being the git committer. I agree with splitting these packages for the long run. Will create repos for other packages and invite you as well. Does it sound good to you? Repos under the public debian/ namespace allows other people to help without much permission issues. On 3/14/24 16:36, Alan M Varghese wrote: Hello Mo, May I address you Mo? I am happy to co-maintain hyprland with you. :) The ITP for hyprland[0] was created by werdahias@ who had created an initial skeleton for the packaging a while ago. Under his advise, I decided to de-vendor all of udis86, tracy and hyprland-protocols. As far as I understand, the Debian policy recommends de-vendoring over including files from other sources. I have been working on this for a while and just uploaded them all to mentors and created RFS for them. Currently I have completed packaging hyprland and all its dependencies to the best of my ability. Regarding the points you shared: 1. I wasn't sure what to do with tracy. I have however de-vendored it and created an RFS for it[1]. But, I am unable to get the GPU traces working on my AMD RX 6600 (for a debug build of Hyprland with tracy enabled). I am not sure if this is because of my device or something else. I have seen some discussion upstream that tracy's GPU traces are not always reliable. Tracy seems to work fine, otherwise. 2. I have de-vendored udis86 too. The library and the included CLI seems to run fine. Here is the RFS[2]. 3. Again, I have separated hyprland-protocols and the RFS is here[3]. You can find the VCS for all hyprland related stuff I did, under the NyxTrail namespace in salsa[4]. The packages all seem to run fine so far. This is my first time packaging for Debian and any feedback is welcome. Let me know how you wish to proceed. Regards, Alan [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868 [4] https://salsa.debian.org/NyxTrail On 3/15/24 01:10, Mo Zhou wrote: Hi Alan, Thank you for your work! I did not check the ITP bugs before we make overlapping efforts: https://salsa.debian.org/debian/hyprlang https://salsa.debian.org/debian/hyprland I just rushed the two packages within a short time the last night. They work properly on Sid with my laptop. I have uploaded hyprlang to NEW without checking ITP https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html The hyprland is still pending as I've not yet finished the debian/copyright part. In terms of build depends of hyprland: 1. tracy is optional. USE_TRACY is by default off. We can build the package without tracy. 2. the udis86 is embedded in the upstream tarball as well. Maybe we can keep it embedded as udis86 is only needed by hyprland 3. hyprland-protocols is also embedded. I suppose it is ok to keep this specific project, instead of splitting the package to increase the required amount of work. Shall we merge our work and co-maintain this? On 3/14/24 14:46, Alan M Varghese wrote: Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: a...@digistorm.in Dear mentors, I am looking for a sponsor for my package "libhyprlang": * Package name : libhyprlang Version : 0.5.0-1 Upstream contact : vaxerski * URL : https://github.com/hyprwm/hyprlang * License : LGPL-3+ * Vcs : https://salsa.debian.org/NyxTrail/hyprlang Section : x11 The source builds the following binary packages: libhyprlang2 - Configuration language for Hyprland (library) libhyprlang-dev - Configuration language for Hyprland (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhyprlang/ Alternat
Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland
I have forked your repo to here:
https://salsa.debian.org/debian/hyprland-protocols
Will sponsor later when I get my other computer.
On 4/15/24 12:19, Alan M Varghese wrote:
Control: tags -1 - moreinfo
Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not <<
0.2
as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends}
(which
will be emoty anyway).
Done and done.
Alan M Varghese (NyxTrail)
Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland
Hi Alan, I granted you with the maintainer access to this repo: https://salsa.debian.org/debian/hyprlang This package has cleared the NEW queue a while ago: https://tracker.debian.org/pkg/hyprlang Could you please push your changes from personal repo to the above repo? I can also do it for you if you don't mind not being the git committer. I agree with splitting these packages for the long run. Will create repos for other packages and invite you as well. Does it sound good to you? Repos under the public debian/ namespace allows other people to help without much permission issues. On 3/14/24 16:36, Alan M Varghese wrote: Hello Mo, May I address you Mo? I am happy to co-maintain hyprland with you. :) The ITP for hyprland[0] was created by werdahias@ who had created an initial skeleton for the packaging a while ago. Under his advise, I decided to de-vendor all of udis86, tracy and hyprland-protocols. As far as I understand, the Debian policy recommends de-vendoring over including files from other sources. I have been working on this for a while and just uploaded them all to mentors and created RFS for them. Currently I have completed packaging hyprland and all its dependencies to the best of my ability. Regarding the points you shared: 1. I wasn't sure what to do with tracy. I have however de-vendored it and created an RFS for it[1]. But, I am unable to get the GPU traces working on my AMD RX 6600 (for a debug build of Hyprland with tracy enabled). I am not sure if this is because of my device or something else. I have seen some discussion upstream that tracy's GPU traces are not always reliable. Tracy seems to work fine, otherwise. 2. I have de-vendored udis86 too. The library and the included CLI seems to run fine. Here is the RFS[2]. 3. Again, I have separated hyprland-protocols and the RFS is here[3]. You can find the VCS for all hyprland related stuff I did, under the NyxTrail namespace in salsa[4]. The packages all seem to run fine so far. This is my first time packaging for Debian and any feedback is welcome. Let me know how you wish to proceed. Regards, Alan [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066873 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066870 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066868 [4] https://salsa.debian.org/NyxTrail On 3/15/24 01:10, Mo Zhou wrote: Hi Alan, Thank you for your work! I did not check the ITP bugs before we make overlapping efforts: https://salsa.debian.org/debian/hyprlang https://salsa.debian.org/debian/hyprland I just rushed the two packages within a short time the last night. They work properly on Sid with my laptop. I have uploaded hyprlang to NEW without checking ITP https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html The hyprland is still pending as I've not yet finished the debian/copyright part. In terms of build depends of hyprland: 1. tracy is optional. USE_TRACY is by default off. We can build the package without tracy. 2. the udis86 is embedded in the upstream tarball as well. Maybe we can keep it embedded as udis86 is only needed by hyprland 3. hyprland-protocols is also embedded. I suppose it is ok to keep this specific project, instead of splitting the package to increase the required amount of work. Shall we merge our work and co-maintain this? On 3/14/24 14:46, Alan M Varghese wrote: Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: a...@digistorm.in Dear mentors, I am looking for a sponsor for my package "libhyprlang": * Package name : libhyprlang Version : 0.5.0-1 Upstream contact : vaxerski * URL : https://github.com/hyprwm/hyprlang * License : LGPL-3+ * Vcs : https://salsa.debian.org/NyxTrail/hyprlang Section : x11 The source builds the following binary packages: libhyprlang2 - Configuration language for Hyprland (library) libhyprlang-dev - Configuration language for Hyprland (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhyprlang/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc Changes for the initial release: libhyprlang (0.5.0-1) UNRELEASED; urgency=low . * Initial release. Closes: #1065352 Regards,
Bug#1066871: RFS: libhyprlang/0.5.0-1 [ITP] -- Configuration language for Hyprland
Hi Alan, Thank you for your work! I did not check the ITP bugs before we make overlapping efforts: https://salsa.debian.org/debian/hyprlang https://salsa.debian.org/debian/hyprland I just rushed the two packages within a short time the last night. They work properly on Sid with my laptop. I have uploaded hyprlang to NEW without checking ITP https://ftp-master.debian.org/new/hyprlang_0.5.0-1~exp1.html The hyprland is still pending as I've not yet finished the debian/copyright part. In terms of build depends of hyprland: 1. tracy is optional. USE_TRACY is by default off. We can build the package without tracy. 2. the udis86 is embedded in the upstream tarball as well. Maybe we can keep it embedded as udis86 is only needed by hyprland 3. hyprland-protocols is also embedded. I suppose it is ok to keep this specific project, instead of splitting the package to increase the required amount of work. Shall we merge our work and co-maintain this? On 3/14/24 14:46, Alan M Varghese wrote: Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: a...@digistorm.in Dear mentors, I am looking for a sponsor for my package "libhyprlang": * Package name : libhyprlang Version : 0.5.0-1 Upstream contact : vaxerski * URL : https://github.com/hyprwm/hyprlang * License : LGPL-3+ * Vcs : https://salsa.debian.org/NyxTrail/hyprlang Section : x11 The source builds the following binary packages: libhyprlang2 - Configuration language for Hyprland (library) libhyprlang-dev - Configuration language for Hyprland (development files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhyprlang/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhyprlang/libhyprlang_0.5.0-1.dsc Changes for the initial release: libhyprlang (0.5.0-1) UNRELEASED; urgency=low . * Initial release. Closes: #1065352 Regards,
Bug#1060034: ITP: python-openai -- OpenAI Python API library
On 1/5/24 12:32, Sam Hartman wrote: Also, I thought that there were several open-source implementations of this API, including from llama.cpp and ctransformers among others. My impression was the OpenAI API had become kind of a standard for gluing something like text-generation-webui to a hosted model not running locally. Or is that some *different* OpenAI API? You are correct. The OpenAI API spec is already a de-facto standard in this area. Every alternative will try to provide the same set of API.
Bug#1060034: ITP: python-openai -- OpenAI Python API library
On 1/5/24 11:45, Ansgar wrote: Then the package should be in main. We do not require external software to be free as well, be that Web APIs provided by Github, Twitter, or the NVidia firmware required for Nouveau, microcode or storage/keyboard/sound/printer firmware required for Linux, ... We would have to move pretty much everything to contrib if that was the case. OK. It seems that I misunderstood it all the time. Mailed ftp-master to reject so I can change the section and reupload. That means src:debgpt can go to the main section as well.
Bug#1060034: ITP: python-openai -- OpenAI Python API library
Package: wnpp Severity: wishlist Owner: debian X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : python-openai Version : 1.6.1 * URL : https://github.com/openai/openai-python * License : Apache-2.0 Programming Lang: Python Description : OpenAI Python API library Dependency of DebGPT. Will be maintained by deep learning team. It will go to the contrib section based on policy section 2.2.2, because this API client requires either (1) paied access to the proprietary backend (2) compatible open-source backend implementations are not yet available in the archive. Thank you for using reportbug
Bug#1057644: multiple python versions in a single .deb package
Control: tags -1 +wontfix I tried this and it turns to be a little bit complicated to support. The code change can be found in the git history, which was reverted by me. The problem is that the file libtorch_python.so.* is specific to one python version, and cannot be shared between py3.11 and py3.12. One of them will break if we do setup.py for both versions. https://github.com/pytorch/pytorch/issues/56046 Upstream is not interested to fix this since libtorch_python.so is already big enough (25MB). I don't want to spend my time for simultaneously supporting multiple python versions anymore. And I don't see any problem by only supporting the default python version. A couple of lines of code change can limit reverse dependencies to a single python version. Patch is appreciated if anybody can make it work. Make sure that both py3.11 and py3.12 `import torch` works correctly.
Bug#976805: Progress?
Anyone interested in imhex can take this ITP over. I can co-maintain it, but now I'm really slow on this given that my bandwidth is spent on other packages. On 11/23/23 17:20, Matthias Geiger wrote: On 23.11.23 21:04, Matthias Geiger wrote: I just saw that imhex embeds some libaries; do you need any help devendoring it ? Poking at the source: lib/third_party: capstone: in debian, libcapstone-dev fmt: in debian, libfmt-dev imgui: in debian, libimgui-dev jthread: NOT in debian, source is at https://github.com/josuttis/jthread llvm-demangle: mix of header files, probably can't be excluded microtar: NOT in debian, a single header from here https://github.com/rxi/microtar miniaudio: in debian, libminiaudio-dev nativefiledialog: NOT in debian, source is at https://github.com/btzy/nativefiledialog-extended nlohmann_json: in debian, nlohmann-json3-dev xdgpp: NOT in debian, just a single header from here: https://sr.ht/~danyspin97/xdgpp/ yara: in debian, libyara-dev lib/external: libromfs: NOT in debian, source is at https://github.com/WerWolv/libromfs libwolv: NOT in debian, source is at https://github.com/WerWolv/libwolv pattern_language: NOT in debian, source is at https://github.com/WerWolv/PatternLanguage So that's seven libraries to package from scratch. Certainly doable. I could be convinced to package those if someone is willing to co-maintain them. best,
Bug#1003170: RM: rabit -- ROM; codebase merged to src:xgboost by upstream
Package: ftp.debian.org Severity: normal Dear ftp-masters, The src:rabit codebase has been merged into src:xgboost. And I have uploaded the latest release of src:xgboost onto unstable. Since src:rabit is nolonger used standalone, I'm requesting the removal of it. Thank you for using reportbug
Bug#1003068: RM: caffe -- ROM; obsolete; has been replaced by new libraries
Package: ftp.debian.org Severity: normal Dear ftp masters, I'd like to request for the removal of src:caffe from unstable. This is an old deep learning framework, and has in fact stopped being developed. Nowadays people use the newer alternatives such as pytorch and tensorflow. I don't think keeping src:caffe in our archive will make any difference in the future. So let's just throw away what should fade out. Thank you for using reportbug
Bug#1000553: transition: simdjson
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, simdjson upstream has bumped the SOVERSION from 5 to 9. It has one (and only one) reverse dependency beyond my maintenance, so I'm opening this transition bug. the reverse depenency src:vast is successfully built locally. Ben file: title = "simdjson"; is_affected = .depends ~ "libsimdjson5" | .depends ~ "libsimdjson9"; is_good = .depends ~ "libsimdjson9"; is_bad = .depends ~ "libsimdjson5"; Thank you for using reportbug
Bug#993029: ranger: No preview for mp(e)g files (mime-type: image/x-tga) and fs saturation with .pam files
Control: reassign -1 imagemagick-6.q16 8:6.9.11.60+dfsg-1.3 Control: severity -1 important Hi, This bug does not belong to ranger. ranger called `identify` from imagemagick on the given video, and identify ends up creating a bulky magick-*.pam file under /tmp and exiting with error. I can reproduce this problem on stable with some of my local video files: lumin ~/Videos> identify xxx.mp4 identify-im6.q16: delegate failed `'ffmpeg' -nostdin -v -1 -i '%i' -vframes %S -vcodec pam -an -f rawvideo -y '%u.pam' 2> '%u'' @ error/delegate.c/InvokeDelegate/1966. It only quit when there is no space in /tmp anymore.
Bug#977344: ITP: orchis-gtk-theme -- a Material Design theme for GNOME/GTK based desktop environments
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: orchis-gtk-theme Version : git master Upstream Author : https://github.com/vinceliuice/ * URL : https://github.com/vinceliuice/Orchis-theme * License : GPL-3.0 Programming Lang: CSS Description : a Material Design theme for GNOME/GTK based desktop environments Generally I don't tweak my desktop environment given a decent default, but this GTK theme is so beautiful that it temporarily changed my mind. It looks pretty under Gnome3, while it's a pity that it does not work under MATE. This package will be maintained under a salsa team where gtk themes are relevant.
Bug#976397: transition: opencv
On Thu, Dec 10, 2020 at 10:17:06PM +0100, Sebastian Ramacher wrote: > What's the status wrt to reverse dependencies? Do they all build with > the new version? Only 4 of them FTBFS. 3 of them failed due to other reasons. OKactiona_3.10.1-1.dsc OKauto-multiple-choice_1.4.0-5.dsc OKcaffe_1.0.0+git20180821.99bd997-8.dsc OKcimg_2.8.4+dfsg-1.dsc OKdarknet_0.0.0+git20180914.61c9d02e-2.dsc OKdigikam_7.1.0-1.dsc OKeviacam_2.1.4-2.dsc OKfreecad_0.19~pre1+git20201123.8d73c8f0+dfsg1-1.dsc FAIL (already FTBFS against opencv 4.0.1) freeture_1.3.0-1.dsc OKgmic_2.4.5-1.1.dsc OKgst-plugins-bad1.0_1.18.2-1.dsc FAIL (already FTBFS against opencv 4.0.1) limereg_1.4.1-4.dsc FAIL (already FTBFS against opencv 3.4.4, 4.0.1) mldemos_0.5.1+git.1.ee5d11f-4.dsc OKmonado_0.3.0-3.dsc FTBFS (#977247) mrpt_2.1.5-1.dsc OKnode-opencv_7.0.0+git20200310.6c13234-1.dsc OKnomacs_3.12.0+dfsg-3.dsc OKopencfu_4.0.0-1.dsc OKopenimageio_2.2.9.0+dfsg-1.dsc OKos-autoinst_4.5.1527308405.8b586d5-4.2.dsc OKotb_7.2.0+dfsg-1.dsc FTBFS (#977248) (header path) php-facedetect_1.1.0-19-g135c72a-1.dsc OKpytorch_1.7.0-2.dsc OKqimgv_0.9.1-2.dsc FTBFS (#977249) ros-opencv-apps_2.0.2-1.dsc FTBFS (#977250) ros-vision-opencv_1.15.0+ds-2.dsc OKsiril_0.99.6-1.dsc OKslowmovideo_0.5+git20190116-3.dsc OKvisp_3.3.0-5.dsc
Bug#977250: FTBFS against opencv 4.5.0
Source: ros-vision-opencv Version: 1.15.0+ds-2 Severity: important Tags: +ftbfs Dear maintainer, package ros-vision-opencv FTBFS against opencv 4.5.0 (experimental).
Bug#977249: FTBFS against opencv 4.5.0
Source: ros-opencv-apps Version: 2.0.2-1 Severity: important Tags: +ftbfs Dear maintainer, package ros-opencv-apps FTBFS against opencv 4.5.0 (experimental).
Bug#977248: FTBFS against opencv 4.5.0
Source: php-facedetect Version: 1.1.0-19-g135c72a-1 Severity: importance Tags: +ftbfs Dear maintainer package php-facedetect FTBFS against opencv 4.5.0 (experimental).
Bug#977247: FTBFS against opencv 4.5.0
Source: mrpt Version: 2.1.5-1 Severity: important Tags: ftbfs Dear maintainer, package mrpt FTBFS against opencv 4.5.0-1 (experimental).
Bug#976805: ITP: imhex -- Hex Editor for Reverse Engineers
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: imhex Version : 1.5.0 * URL : https://github.com/WerWolv/ImHex * License : GPL-2.0 Programming Lang: C++ Description : Hex Editor for Reverse Engineers This will be maintained under security-tools team. (applying salsa access shortly)
Bug#976397: transition: opencv
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The opencv version in unstable is relatively old. I'd like to make the latest version of opencv into the next stable release. Ben file: title = "opencv"; is_affected = .depends ~ "libopencv.*4\.2" | .depends ~ "libopencv.*4\.5"; is_good = .depends ~ "libopencv.*4\.5"; is_bad = .depends ~ "libopencv.*4\.2"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#976264: please avoid depending on libatlas3-base
Source: jblas Version: 1.2.4-2 Severity: important Tags: +patch Hi maintainers, Please avoid the usage of a specific BLAS/LAPACK implementation. See #943712 and the mentioned MBF mail. diff --git a/debian/control b/debian/control index 6857eb5..b659673 100644 --- a/debian/control +++ b/debian/control @@ -10,7 +10,8 @@ Build-Depends: default-jdk, gfortran, junit4, - libatlas-base-dev, + libblas-dev, + liblapack-dev, locales, ruby Standards-Version: 4.1.4 diff --git a/debian/rules b/debian/rules index 42a4826..06873fa 100755 --- a/debian/rules +++ b/debian/rules @@ -16,7 +16,7 @@ override_dh_auto_build: localedef -f UTF-8 -i en_US ./debian/tmp/locale/en_US.UTF-8/ export LOCPATH=$(CURDIR)/debian/tmp/locale/ && \ export LC_ALL=en_US.UTF-8 && \ - ./configure --libpath=/usr/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH)/atlas + ./configure --libpath=/usr/lib/$(DEB_HOST_MULTIARCH):/usr/lib/$(DEB_HOST_MULTIARCH)/blas:/usr/lib/$(DEB_HOST_MULTIARCH)/lapack --lapack-build --built-type=lapack export LOCPATH=$(CURDIR)/debian/tmp/locale/ && \ export LC_ALL=en_US.UTF-8 && \ $(MAKE)
Bug#975369: ITP: faiss -- library for efficient similarity search and clustering of dense vectors
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: faiss Version : 1.6.4 Upstream Author : facebook research * URL : http://www.example.org/ * License : MIT Programming Lang: C++, Python Description : library for efficient similarity search and clustering of dense vectors Will be maintained by deep learning team.
Bug#973341: ITP: libnop -- libnop: C++ Native Object Protocols
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: libnop Upstream Author : google * URL : https://github.com/google/libnop * License : Apache-2.0 Programming Lang: C++ Description : libnop: C++ Native Object Protocols PyTorch 1.7.0 build-depends on tensorpipe snapshot XXX; tensorpipe snapshot XXX build-depends on libnop snapshot YYY. I hold an neutral opinion towards the invention of `git submodule`, as long as there is no recursion and force-pushes.
Bug#973002: ITP: tensorboard -- TensorFlow's Visualization Toolkit
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: tensorboard Version : 2.3.0 Upstream Author : TensorFlow authors * URL : https://github.com/tensorflow/tensorboard * License : Apache-2.0 Programming Lang: TypeScript, Python Description : TensorFlow's Visualization Toolkit TensorFlow's visualization tool can be used standalone (i.e. without tensorflow). It's very useful for training networks using PyTorch as well. This package will be maintained by Debian Deep Learning Team for sake of unblocking the pytorch-lightning package.
Bug#972804: ITP: yyjson -- A high performance JSON library written in ANSI C.
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: yyjson Upstream Author : https://github.com/ibireme * URL : https://github.com/ibireme/yyjson * License : MIT/X Programming Lang: C Description : A high performance JSON library written in ANSI C. simdjson upstream plans to add yyjson as a fallback in 0.7 release. https://github.com/simdjson/simdjson/issues/1245 will be maintained under salsa.d.o/debian/yyjson
Bug#972687: ITP: pytorch-lightning -- lightweight PyTorch wrapper for high-performance AI research
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: pytorch-lightning Version : 1.0.0 * URL : https://github.com/PyTorchLightning/pytorch-lightning * License : Apache-2.0 Programming Lang: Python Description : lightweight PyTorch wrapper for high-performance AI research I like this abstraction layer of pytorch. This package will be maintained by Debian Deep Learning Team.
Bug#972103: RFS: fonts-cascadia-code/2009.14-1 -- monospaced font designed to enhance appearance of Windows Terminal
Control: tag -1 +moreinfo Hi Gürkan, Missing build dependency "statmake" # dpkg-buildpackage - Command: dpkg-buildpackage -us -uc -b -rfakeroot dpkg-buildpackage: info: source package fonts-cascadia-code dpkg-buildpackage: info: source version 2009.14-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Gürkan Myczko dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf debian/rules override_dh_auto_build make[1]: Entering directory '/<>' python3 build.py Traceback (most recent call last): File "build.py", line 15, in from statmake import lib, classes ModuleNotFoundError: No module named 'statmake' make[1]: *** [debian/rules:10: override_dh_auto_build] Error 1 make[1]: Leaving directory '/<>' make: *** [debian/rules:7: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Build finished at 2020-10-21T07:45:04Z
Bug#972566: python3-opencv: build python extensions for all supported python versions
Hi Drew, Thanks for the report. python3-opencv is built using cmake. I have no idea on the way of enabling multiple python3 builds for the current cmake build system. On Tue, Oct 20, 2020 at 07:40:44PM +0800, Drew Parsons wrote: > Package: python3-opencv > Version: 4.2.0+dfsg-6+b4 > Severity: normal > > Currently python3-opencv only builds python extensions > (/usr/lib/python3/dist-packages/cv2.cpython-38-x86_64-linux-gnu.so) > for the default version of python (python3.8 at the moment). > > It would be nice if the extension module could be built for all > supported pythons (python3.9 is now in the archive). > > Currently opencv Build-Depends: python3-dev, hence only builds against > the default python. > > Will the other python versions be built automatically if that is updated to > Build-Depends: python3-all-dev ? > > -- > debian-science-maintainers mailing list > debian-science-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#972320: RM: mkl-dnn -- NVIU; replaced by src:onednn due to upstream rename
Package: ftp.debian.org Severity: normal Dear ftp-master, I'm the maintainer of src:mkl-dnn, which has been recently renamed into src:onednn by upstream. Currently both src:onednn and src:mkl-dnn exist in our archive. So let's remove the old src:mkl-dnn.
Bug#972068: arpack: provide 64-bit (ILP64) build
On Mon, Oct 12, 2020 at 12:05:31PM +0800, Drew Parsons wrote: > This would be an extra set of packages (e.g. libarpack2-64-dev, > libarpack2-64) providing libarpack64.so (or libarpack-64.so) alongside > libarpack.so (i.e. coinstallable). It would be built against > libblas64-dev instead of libblas-dev. Maybe libarpack64-2-dev? The "64" is a part of SONAME. e.g. the packages libblas64-dev, libblas64-3 are not named as something like libblas3-64-dev and libblas3-64. Plus, our convension is that the last number denotes the SOVERSION, right? And do we mean SOVERSION=64 by libarpack2-64 (which I think definitely not).
Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation
Hi Bastian, On Mon, Oct 05, 2020 at 10:02:43AM +0200, Bastian Blank wrote: > > * License : CC-BY-SA > I hope you checked that? Well, TBH I didn't scrutinize all files on the source tree -- that step is postponed until the debianization procedure. As a project of the openzfs organization, I excpect some CDDL bits even if the global license is CC-BY-SA. > Example: > > | % head -n 6 docs/msg/ZFS-8000-14/index.rst > | .. > |CDDL HEADER START > | > |The contents of this file are subject to the terms of the > |Common Development and Distribution License (the "License"). > |You may not use this file except in compliance with the License. Indeed. > > Programming Lang: python > Ha ha. Umm ... quite common for sphinx doc projects. But I'd be glad if you find it amusing.
Bug#971692: ITP: openzfs-docs -- OpenZFS Documentation
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: openzfs-docs Version : waiting for the first release Upstream Author : OpenZFS authors * URL : https://github.com/openzfs/openzfs-docs * License : CC-BY-SA Programming Lang: python Description : OpenZFS Documentation Will be maintained by the ZFS on Linux team.
Bug#971650: ITP: ncnn -- high-performance neural network inference framework optimized for the mobile platform
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org * Package name: ncnn * URL : https://github.com/Tencent/ncnn * License : BSD-3-Clause Programming Lang: C++ Description : high-performance neural network inference framework optimized for the mobile platform I'm intrigued by this framework due to its vulkan support -- another route of hardware acceleration -- and the vulkan dependencies are already present in our archive -- this is a short path. Will be maintained by Debian Deep Learning Team.
Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade
Control: severity -1 important Control: tag -1 +moreinfo I cannot reproduce this with either linux 5.7 or linux 5.8 on sid.
Bug#919485: closing
Control: close -1 the upstream just resurrected
Bug#970777: Acknowledgement (fish: tty settings are not resetted on exit)
Hi Boyuan, Thanks for the notice. I think you can directly go ahead and upload it with the severity:important bugfix, since I'm quite busy, and Tristan has an lowNMU tag. On Sun, Sep 27, 2020 at 08:56:44PM -0400, Boyuan Yang wrote: > Hi Tristan, > > I was contacted by the bug submitter about this important bug and > verified the severity and proposed fix. I'm wondering if you are going > to make a stable upload soon to fix this issue. > > I received some unofficial messages from Mo Zhou that he is too busy to > handle it right now. > > Please let me know if this will be handled in the near future. If not > (or if there's no reply within 1 week), I plan to do a NMU stable > upload and contact the Release Team about this stable upload. > > Thanks and looking forward to your reply. Please include me in the CC > list. signature.asc Description: PGP signature
Bug#970575: ITP: pytorch-geometric -- Geometric Deep Learning Extension Library for PyTorch
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pytorch-geometric * URL : https://github.com/rusty1s/pytorch_geometric * License : MIT/X Programming Lang: Python Description : Geometric Deep Learning Extension Library for PyTorch Debian Deep Learning Team
Bug#970269: RFA: fzf -- general-purpose command-line fuzzy finder
Package: wnpp Severity: normal I request an adopter for the fzf package. The package description is: It's an interactive Unix filter for command-line that can be used with any list; files, command history, processes, hostnames, bookmarks, git commits, etc. . Refer /usr/share/doc/fzf/README.Debian for quick instructions on how to add keybindings for Bash, Zsh, Fish to call fzf. It's an interactive Unix filter for command-line that can be used with any list; files, command history, processes, hostnames, bookmarks, git commits, etc. . Refer /usr/share/doc/fzf/README.Debian for quick instructions on how to add keybindings for Bash, Zsh, Fish to call fzf. I'm no longer interested in maintaining software written in go.
Bug#968426: ITP: tensorpipe -- A tensor-aware point-to-point communication primitive for machine learning
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tensorpipe Upstream Author : pytorch developers * URL : https://github.com/pytorch/tensorpipe * License : BSD Programming Lang: C++ Description : A tensor-aware point-to-point communication primitive for machine learning New PyTorch dependency. required by pytorch 1.6.0
Bug#968219: ITP: openpbs -- An HPC workload manager and job scheduler for desktops, clusters, and clouds.
Package: wnpp Severity: wishlist Owner: Mo Zhou X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: openpbs Version : 20.0.1 Upstream Author : Name * URL : http://www.example.org/ * License : AGPL-3 Programming Lang: C, python, shell Description : An HPC workload manager and job scheduler for desktops, clusters, and clouds. I'm wondering why it is absent in debian.
Bug#964543: ITP: pymc3 -- Bayesian statistical modeling and Probabilistic Machine Learning
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pymc3 * URL : https://github.com/pymc-devs/pymc3 * License : Apache-2.0 Programming Lang: Python Description : Bayesian statistical modeling and Probabilistic Machine Learning Debian Deep Learning Team.
Bug#963250: openblas: Please build on armel
Hi, I second that enabling openblas on armel makes basically no sense. If you want a BLAS implementation that is possibly slightly faster than the standard src:lapack, please try using src:blis instead of src:openblas on armel, since src:blis contains some generic optimizations. On Sun, Jun 21, 2020 at 07:33:21PM +0200, Sébastien Villemot wrote: > Le dimanche 21 juin 2020 à 17:28 +0300, Adrian Bunk a écrit : > > On Sun, Jun 21, 2020 at 02:54:22PM +0200, Sébastien Villemot wrote: > > > Le dimanche 21 juin 2020 à 14:40 +0300, Adrian Bunk a écrit : > > > > Source: openblas > > > > Version: 0.3.9+ds-2 > > > > Severity: normal > > > > Tags: patch > > > > > > > > A debdiff for building openblas on armel is attached. > > > > > > What’s the point of building openblas on armel? > > > > > > Openblas is a highly optimized BLAS library, which only makes sense on > > > machines with hardware floating point. > > > > > > For armel, reference BLAS (as provided by src:lapack) is probably as > > > efficient. > > > > I don't think "efficiency" is relevant when using either on armel > > hardware... > > Sure. But the difference is that src:lapack is standard Fortran 77, and > should thus be well supported on armel. On the contrary, src:openblas > is full of hardware-specific hacks, assembly code and the like; and > upstream does not support armel. > > So enabling it on armel could mislead users into believing that > openblas is supported and/or useful on their platform, which it is not. > > Also, upstream will not help us if there is a regression, and the > package is likely to take forever to build given the low performance of > armel (building it is already very resource hungry on an recent amd64 > machine). Y. > > What I am interested in is that reverse dependencies behave > > (and break) the same on armel as they do on armhf. > > Note that since src:lapack and src:openblas provide the same ABI, the > recommended practice for packagers is to never explicitly (build- > )depend on openblas (or at most to put it second in an alternative, or > as a Recommends). > > But in any case, I don’t understand why we should aim at identical > behaviour of armel and armhf in the field of number crunching. Those > two architectures are very different in that area, in a number of > respects, and this is unavoidable given the hardware differences. We should not expect the same bahaviour of hardware floating point calculation from software-emulated float point operations. > So I personally see more inconvenients than advantages to implementing > this. > > Maybe my co-maintainer Mo Zhou could weigh in? * If the reverse dependency must use openblas, then please disable the reverse dependency on armel. Nobody sane does numerical calculation on armel. * If the standard src:lapack is too slow, please try the alternative src:blis instead of src:openblas. > -- > ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot > ⣾⠁⢠⠒⠀⣿⡁ Debian Developer > ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name > ⠈⠳⣄ https://www.debian.org > > -- > debian-science-maintainers mailing list > debian-science-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#958888: ITP: pytorch -- Tensors and Dynamic neural networks in Python with strong GPU acceleration
Hi Petter, Sorry. Nothing new except for the packages pending in NEW. On Wed, Jun 03, 2020 at 02:13:52PM +0200, Petter Reinholdtsen wrote: > [Mo Zhou] > > I've uploaded all the necessary build dependencies to the NEW queue. > > Now I'm waiting for the upstream to merge my pull requests. > > > > will be maintained under Debian Deep Learning Team > > Hi. Any news on this? See there are two versions pending in NEW. > > -- > Happy hacking > Petter Reinholdtsen
Bug#962028: ITP: python-rich -- Rich is a Python library for rich text and beautiful formatting in the terminal.
Hi Sandro, I saw it. Looking forward to the package. Thanks! On Tue, Jun 02, 2020 at 11:41:55AM -0400, Sandro Tosi wrote: > I already filed an ITP for rich: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954301
Bug#962028: ITP: python-rich -- Rich is a Python library for rich text and beautiful formatting in the terminal.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: python-rich * URL : https://github.com/willmcgugan/rich * License : MIT Programming Lang: Python Description : Rich is a Python library for rich text and beautiful formatting in the terminal. will be maintained under DPMT
Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock
> Just one question: did you try to rebuild it from source without > changing anything? Maybe it’s just the rebuild that fixed it, and not > the flag change. Rebuilt without change: hang with libopenblas0-pthread Rebuilt with USE_TLS=0: hang Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang Rebuilt with "-Wl,-Bsymbolic-functions" stripped: pass
Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock
> Just one question: did you try to rebuild it from source without > changing anything? Maybe it’s just the rebuild that fixed it, and not > the flag change. Rebuilt without change: hang with libopenblas0-pthread Rebuilt with USE_TLS=0: hang Rebuilt with USE_SIMPLE_THREADED_LEVEL3=1: hang Rebuilt with "-Wl,-Bsymbolic-functions" stripped: pass
Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock
Control: tags -1 -moreinfo Hi Sébastien, Good catch! I tried to remove the mentioned LDFLAG DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions" and rebuilt the openblas 3.8 package. Then deadlock issue disappeared.
Bug#961725: libopenblas-dev: On some cpus, openmp and pthread dead-lock
Control: severity -1 important Control: tags -1 +moreinfo Clarification: possibly a Ubuntu bug Hello guys, The way to reproduce with docker + ubuntu devel (20.10) 1. docker image pull ubuntu:devel 2. docker run -ti ubuntu:devel 3. apt update -y ; apt upgrade -y 4. apt install -y r-base-core 5. Rscript -e "example(solve)" # good with netlib 6. apt install -y libopenblas-dev 7. Rscript -e "example(solve)" # hang The way to reproduce with nspawn/chroot + ubuntu focal (20.04) if you don't have docker 1. mkdir Focal 2. debootstrap focal Focal/ 3. systemd-nspawn -D Focal 4. apt update -y; apt upgrade -y 5. apt install -y r-base-core 6. Rscript -e "example(solve)" # good with netlib 7. apt install -y libopenblas-dev 8. Rscript -e "example(solve)" # hang The way to reproduce with *. + debian 1. Not yet reproducible.
Bug#961565: ITP: skorch -- A scikit-learn compatible neural network library that wraps PyTorch
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: skorch * URL : https://github.com/skorch-dev/skorch * License : BSD-3 Description : A scikit-learn compatible neural network library that wraps PyTorch Debian Deep Learning Team
Bug#961556: ITP: stan -- a state-of-the-art platform for statistical modeling and high-performance statistical computation
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: stan * URL : https://github.com/stan-dev/stan * License : bsd-3 Description : a state-of-the-art platform for statistical modeling and high-performance statistical computation
Bug#961557: ITP: stan-math -- a C++ template library for automatic differentiation of any order
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: stan-math * URL : https://github.com/stan-dev/math * License : bsd-3 Description : a C++ template library for automatic differentiation of any order
Bug#961029: Request for new mailing list: debian-ai
Hi, I confirm that the list I'm going to request for is exactly debian-ai and it's not going to be changed again. On Fri, May 22, 2020 at 05:58:00AM +, Mo Zhou wrote: > Control: retitle -1 Request for new mailing list: debian-ai > > Thanks for the various feedbacks. As pointed out by lamby, the > "debian-mlhwaccl" may be quite hard to search. Meanwhile, the name can > be overlength if we expand that abbreviation. > > So I'm proposing to use a new list name: debian-ai > instead of the old: debian-mlhwaccl > > Name: debian-ai > Short-Desc: Artificial Intelligence Software Development in Debian > Long-Desc: Development of artificial intelligence software, such as machine > learning, deep learning, compilers and hardware acceleration software stacks. > The topics for this list may include any one of the following (but not > limited): > * Mahcine Learning: sklearn, xgboost, AutoML, ... > * Deep Learning: tensorflow, pytorch, mxnet, cntk, ... > * Computer Vision: opencv, skimage, ... > * Computational Linguistics: nltk, spacy, ... > * Hardware Acceleration: CUDA, ROCm, OpenCL, SYCL, SIMD > * Compiler: LLVM (for MLIR, SPIR-V, SYCL), GCC (gcc-offload-nvptx) > And sometimes the topics in this list may be complex intersections of > the mentioned keywords. > Category: development > Subscription-Policy: open > Post-Policy: open > Web-Archive: yes >
Bug#961029: Request for new mailing list: debian-ai
Control: retitle -1 Request for new mailing list: debian-ai Thanks for the various feedbacks. As pointed out by lamby, the "debian-mlhwaccl" may be quite hard to search. Meanwhile, the name can be overlength if we expand that abbreviation. So I'm proposing to use a new list name: debian-ai instead of the old: debian-mlhwaccl Name: debian-ai Short-Desc: Artificial Intelligence Software Development in Debian Long-Desc: Development of artificial intelligence software, such as machine learning, deep learning, compilers and hardware acceleration software stacks. The topics for this list may include any one of the following (but not limited): * Mahcine Learning: sklearn, xgboost, AutoML, ... * Deep Learning: tensorflow, pytorch, mxnet, cntk, ... * Computer Vision: opencv, skimage, ... * Computational Linguistics: nltk, spacy, ... * Hardware Acceleration: CUDA, ROCm, OpenCL, SYCL, SIMD * Compiler: LLVM (for MLIR, SPIR-V, SYCL), GCC (gcc-offload-nvptx) And sometimes the topics in this list may be complex intersections of the mentioned keywords. Category: development Subscription-Policy: open Post-Policy: open Web-Archive: yes
Bug#961182: ITP: nni -- An open source AutoML toolkit for automate machine learning lifecycle
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: nni * URL : https://github.com/microsoft/nni * License : MIT/Expat Programming Lang: Python Description : An open source AutoML toolkit for automate machine learning lifecycle AutoML. Debian Deep Learning Team.
Bug#961181: ITP: tpot -- Automated Machine Learning tool that optimizes machine learning pipelines using genetic programming
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: tpot * URL : https://github.com/EpistasisLab/tpot * License : LGPL-3.0 Programming Lang: Python Description : Automated Machine Learning tool that optimizes machine learning pipelines using genetic programming AutoML. Debian Deep Learning Team.
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Hi Ricardo, Glad to hear that, and please keep up your good work :-) Feel free to ping me for help in the work if you need. On Wed, May 20, 2020 at 08:31:12AM +0200, Ricardo Ribalda Delgado wrote: > Hi Mo > > Thanks for your offer. I already packaged it, and have a mentor. > > https://salsa.debian.org/ribalda-guest/ugrep > > I think it is a package simple enough that does not need > co-maintainer, but I keep you offer in mind in case I cannot maintain > it in the future or if I fail to include the package in Debian. > > Thanks! > > On Wed, May 20, 2020 at 2:29 AM Mo Zhou wrote: > > > > Hi Ricardo, > > > > I tried it out and it looks quite interesting, since it has some more > > features that the other grep implementations (including ripgrep) do not > > have. I'm interested in co-maintaining this package if you need help. > > > > On Tue, May 19, 2020 at 06:13:16PM +0200, Ricardo Ribalda Delgado wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: Ricardo Ribalda Delgado > > > > > > * Package name: ugrep > > > Version : 2.1.1 > > > Upstream Author : Robert van Engelen > > > * URL : https://github.com/Genivia/ugrep/wiki > > > * License : BSD-3-Clause > > > Programming Lang: C++ > > > Description : Universal grep: ultra fast searcher of file systems, > > > text and binary files, source code, archives, compressed files, > > > documents, and more. > > > > > > > > > NEW ultra fast grep with interactive query UI: search file systems, > > > text, source code, binary files, archives (cpio/tar/pax/zip), compressed > > > files (zip/gz/Z/bz2/lzma/xz), documents, and more. > > > > > > It is also very useful when grepping on codebase with unicode files. > > > > > > I plan to send with a sponsor (zumbi). Hopefuly I will be able to > > > upload packages on my own ;). > > > > > > > -- > Ricardo Ribalda
Bug#961045: ITP: ugrep -- Universal grep: ultra fast searcher of file systems, text and binary files, source code, archives, compressed files, documents, and more. It is also very useful when searchin
Hi Ricardo, I tried it out and it looks quite interesting, since it has some more features that the other grep implementations (including ripgrep) do not have. I'm interested in co-maintaining this package if you need help. On Tue, May 19, 2020 at 06:13:16PM +0200, Ricardo Ribalda Delgado wrote: > Package: wnpp > Severity: wishlist > Owner: Ricardo Ribalda Delgado > > * Package name: ugrep > Version : 2.1.1 > Upstream Author : Robert van Engelen > * URL : https://github.com/Genivia/ugrep/wiki > * License : BSD-3-Clause > Programming Lang: C++ > Description : Universal grep: ultra fast searcher of file systems, text > and binary files, source code, archives, compressed files, documents, and > more. > > > NEW ultra fast grep with interactive query UI: search file systems, > text, source code, binary files, archives (cpio/tar/pax/zip), compressed > files (zip/gz/Z/bz2/lzma/xz), documents, and more. > > It is also very useful when grepping on codebase with unicode files. > > I plan to send with a sponsor (zumbi). Hopefuly I will be able to > upload packages on my own ;). >
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
On Tue, May 19, 2020 at 12:06:00PM +0800, 铜豌豆 Linux wrote: > * New maintainer (Closes: #910181) When closing an "Orphan" bug you should also remove the previous maintainer from the Maintainers/Uploaders list. We have some reference materials but it seemed to have missed that point https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package
Bug#961029: Request for new mailing list: debian-mlhwaccl
Package: lists.debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org (I think I should CC -devel since I'm requesting a NEW dev ML) Hi list master, I'd like to request for a new public, and archived mailing list Name: debian-mlhwaccl Short-Desc: "Debian's Machine Learning & Hardware Acceleration" Long-Desc: Development of Machine/Deep Learning Software and Corresponding Hardware Acceleration Measures incl. ROCm, OpenCL, SYCL and CUDA Category: obviously a dev list Subscription-Policy: open Post-Policy: open Web-Archive: yes (we definitely need an archive) Our demand / Rationale: 1. we need an archived mailing list to better coordinate the works related to deep learning / machine learning and hardware acceleration (including ROCm, CUDA, OpenCL, SYCL) specific to machine learning applications. Debian science team maling address is not quite appropriate for the topics. 2. we need an archived mailing list as the maintainer address for the ROCm team to better coordinate the works. We should not abuse debian science team's alioth mailing list address as the maintainer address neither. 3. we need an archived mailing list for discussing about the development of debian deep learning team. The machine learning and deep learing subareas are already significant enough to form a dedicated interest group inside debian. Teams involved: Debian ROCm Team, Debian Deep Learning Team Expected key words for the mailing list: tensorflow, pytorch, bazel, sklearn, opencl, sycl, rocm, cuda, llvm, xla (tensorflow), openmpi as you see, some times the topics could be off-topic to debian-science, and the "machine learning & hardware acceleration" things always involves complicated intersection of various areas. It could be better if we have a dedicated list for the whole thing! thank you very much I'm following https://www.debian.org/MailingLists/HOWTO_start_list
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
Hi atzlinux, I appreciate your work on the Chinese-related packages, but only when people try to do something other than repetitive householding works will they gain further knowledge and skills. This way is inevitable if you really want to become a DD, since you have to first prove your expertise to the advocators. When you gained enough experience in debian development, you will discover that some packages without householding for years are still in good shape. Besides, the package uploading tally is not strictly proportional to ones expertise and influence within this community. Just two tips for you as you have opened an AM process. On Tue, May 19, 2020 at 12:06:00PM +0800, 铜豌豆 Linux wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "fortune-zh" > > * Package name : fortune-zh > Version : 2.96 > Upstream Author : xiao sheng wen > * URL : [fill in URL of upstream's web site] > * License : GPL-3.0+ > * Vcs : https://salsa.debian.org/chinese-team/fortunes-zh > Section : games > > It builds those binary packages: > > fortunes-zh - Chinese Data files for fortune > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/fortune-zh > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_2.96.dsc > > Changes since the last upload: > > [ 肖盛文 ] > * d/control: > - Bump debhelper-compat (= 13) > - Bump Standards-Version: 4.5.0 > - add Rules-Requires-Root: no > - add New Uploaders: xiao sheng wen > * d/copyright: add Upstream-Contact: > * New maintainer (Closes: #910181) > > Regards,
Bug#960981: ITP: rocr-runtime -- HSA Runtime API and runtime for ROCm
On Tue, May 19, 2020 at 08:41:47PM +0900, Norbert Preining wrote: > > Packaging ROCm requires a forked LLVM. Will you package that fork, and > > Thanks for bringing this up. Up to now all the ITP don't require the > forked llvm. We have one repository (rocm-hip) in preparation for which > the llvm-fork is necessary. And there are other's I am preparing. > > Our plan (at the moment basically Mo Zho and me) was to package it into ^ u > a separate directory /usr/lib/llvm/roc/ (like Gentoo does) or into any > similar place. Yes. Aligning with Gentoo looks good, as long as we really need an forked LLVM. Benda Xu (gentoo dev) told me that his latest investigation suggests that AMD's modifications have been upstreamed. But no AMD people responded the question. https://github.com/RadeonOpenCompute/hcc/issues/1421 We'll have to confirm that. > But I am more than open for help with the llvm-roc build, since this not > even finishes on my computer without blowing it up ATM ... My experience is that LLVM build often ends up being killed by the OOM killer, and I can only use -j4 on a machine with 32Gigs of RAM. The "-gsplit-dwarf" CFLAG may help when doing the parellel linking, but I still have not tried it with LLVM yet. > PREINING Norbert https://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#960981: ITP: rocr-runtime -- HSA Runtime API and runtime for ROCm
Hi doko, I've not dug into this deep enough by myself. AFAIK, however, AMD seemd to have upstreamed their LLVM bits specific to LLVM https://github.com/RadeonOpenCompute/hcc/issues/1421 https://github.com/RadeonOpenCompute/hcc#deprecation-notice I asked the corresponding Gentoo developer and he confirms that. On Tue, May 19, 2020 at 11:10:48AM +0200, Matthias Klose wrote: > > Packaging ROCm requires a forked LLVM. Will you package that fork, and > > - if yes, how do you plan do maintain the set of shared libraries >provided by the two versions. > > - if no, how do you integrate with the LLVM found in Debian > > Matthias
Bug#960816: ITP: snapraid -- A backup program for disk arrays.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: snapraid * URL : https://github.com/amadvance/snapraid * License : GPL-3 Programming Lang: C Description : A backup program for disk arrays.
Bug#960471: ITP: prophet -- Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: prophet Upstream Author : Facebook * URL : https://github.com/facebook/prophet * License : MIT Programming Lang: Py, R Description : Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth. Time series analysis tool. Will be maintained by debian science team.
Bug#960428: ITP: blingfire -- Bing's Finite State machine and REgular expression manipulation library
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: blingfire Upstream Author : Microsoft * URL : https://github.com/microsoft/BlingFire * License : MIT Programming Lang: C++, python Description : Bing's Finite State machine and REgular expression manipulation library useful as a preprocessing tool for computational linguistics. This library will be maintained by Debian Deep Learning Team.
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
Hi Adam, Thanks for the notification! It has been uploaded just now. Was indulging in the pytorch related stuff. On Fri, May 01, 2020 at 11:22:54AM +0100, Adam D. Barratt wrote: > Ping? (On both this question and the zfs-linux upload.) > > The window for getting fixes into 10.4 closes during this weekend. > > Regards, > > Adam >
Bug#959183: ITP: python-opcodes -- Database of CPU Opcodes
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: python-opcodes * URL : https://github.com/Maratyszcza/Opcodes * License : BSD-2 Description : Database of CPU Opcodes NNPACK deps NNPACK is a pytorch performance booster Debian deep learining team
Bug#959184: ITP: python-peachpy -- x86-64 assembler embedded in Python
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: python-peachpy * URL : https://github.com/Maratyszcza/PeachPy * License : bsd2 Description : x86-64 assembler embedded in Python NNPACK deps NNPACK is pytorch deps (performance booster)
Bug#926416: licensing Re: ITP: conda
Hi Rebecca, Conda itself, as a python package manager indeed does not require nonfree blobs such as intel-mkl to function. Only some of the the packages it downloads require, say intel-mkl, cudnn or alike. However, if conda toolchains can be used to setup standalone servers, I'll not stand in the way as long as anyone is willing to work on that. On Wed, Apr 29, 2020 at 06:20:49PM +0100, Rebecca N. Palmer wrote: > Note that these are distinct: > - conda, the package manager itself; BSD-3 licensed > - Anaconda Individual Edition, a bundle of conda + some commonly-used > packages; non-DFSG-free as it includes intel-mkl and cudnn > (https://docs.anaconda.com/anaconda/eula/) > - Anaconda repository, the server conda uses by default > (https://repo.anaconda.com/pkgs/); has a no-unauthorized-mirrors policy > > conda does not have to use its default server, as packages can be created > with conda-build (also BSD-3 licensed) and distributed with standard web > servers: > https://conda.io/projects/conda/en/latest/user-guide/tasks/create-custom-channels.html > > Did you find an intel-mkl dependency in conda itself, or only in packages?
Bug#959121: ITP: qnnpack -- Quantized Neural Network PACKage (pytorch performance)
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: qnnpack * URL : https://github.com/pytorch/qnnpack * License : BSD-3 Programming Lang: C++ Description : Quantized Neural Network PACKage (pytorch performance) pytorch performance booster as suggested by upstream debian deep learning team
Bug#959122: ITP: nnpack -- Acceleration package for neural networks on multi-core CPUs
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: nnpack * URL : https://github.com/Maratyszcza/NNPACK * License : BSD-2 Programming Lang: C, C++ Description : Acceleration package for neural networks on multi-core CPUs pytorch performance booster as suggested by upstream debina deep learning team
Bug#959123: ITP: fbgemm -- Facebook GEneral Matrix Multiplication
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: fbgemm * URL : https://github.com/pytorch/FBGEMM * License : BSD-3 Programming Lang: C++ Description : Facebook GEneral Matrix Multiplication pytorch performance booster as suggested by upstream debian deep learning team
Bug#958950: RM: torch3 -- RoQA; Deprecated Upstream
Package: ftp.debian.org Severity: normal I'm not the maintainer. Torch3 is already dead. We should remove it. There is an RFP for its successor Torch5, but Torch5 had never entered archive Torch7 had been packaged for buster (lua-torch-* packages), but removed due to deprecation The successor of Torch7 is Pytorch. I'm working on packaging pytorch.
Bug#958947: RM: sleef [armel mips64el mipsel s390x] -- ROM; remove nolonger supported architectures
Package: ftp.debian.org Severity: normal (please explain the reason for the removal here) upstream broke the support for armel, mips*, and s390x in the latest release I'd like to request for removal of these architectures to unblock migration Note: this was a request for a partial removal from testing, converted in one for unstable
Bug#958652: ITP: foxi -- ONNXIFI with Facebook Extension
Control: close -1 It's pointness to package this standalone. It's never used by any other package than pytorch. And pytorch only needs a small part of its code. The rest part of foxi, that pytorch does not need, FTBFS. So I choose to embed the necessary files of foxi to src:pytorch
Bug#945834: ITP: trisycl -- Generic system-wide modern C++ for heterogeneous platforms with SYCL from Khronos Group
Control: close -1 TriSYCL is cooperating with intel. Maintaing the LLVM/SYCL is already difficult enough for the open source community, let alone two implemtnations. We should wait for intel to upstream their SYCL component to LLVM upstream.
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
On Sun, Apr 26, 2020 at 03:25:22PM +0100, Adam D. Barratt wrote: > On Wed, 2020-04-22 at 05:21 +0000, Mo Zhou wrote: > > The whole fix involes two parts: a part goes to src:zfs-linux and the > > other goes to src:spl-linux. Now that the updated src:spl-linux is > > already uploaded, and I'm now asking for the permission to upload the > > updated src:zfs-linux. Which includes two upstream commits fixing > > potential deadlock issues. > > What happens if a user tries using the current spl-dkms with the newer > zfs-dkms, or vice versa? I forgot to add Depends: spl-dkms (>= 0.7.12-2+deb10u1, s-p-u) into the debdiff of zfs-linux. Actually zfs-linux (= 0.7.12-2+deb10u1, buster) have no problem to build atop spl-linux (= 0.7.12-2, buster) or (= 0.7.12-2+deb10u1, s-p-u); while zfs-linux (= 0.7.12-2+deb10u2, s-p-u) will FTBFS atop spl-linux (= 0.7.12-2, buster) In that sense we'd better deal with spl-linux and zfs-linux synchronously. > Regards, > > Adam
Bug#958893: ITP: pytorch-ignite -- High-level library to help with training neural networks in PyTorch
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pytorch-ignite * URL : https://github.com/pytorch/ignite * License : BSD-3 Programming Lang: py Description : High-level library to help with training neural networks in PyTorch make pytorch even easier to use debian deep learning team
Bug#958892: ITP: pytorch-vision -- Datasets, Transforms and Models specific to Computer Vision
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pytorch-vision * URL : https://github.com/pytorch/vision * License : BSD-3 Programming Lang: C++,py Description : Datasets, Transforms and Models specific to Computer Vision a very important extra module for pytorch users debian deep learning team
Bug#958890: ITP: pytorch-audio -- Data manipulation and transformation for audio signal processing, powered by PyTorch
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pytorch-audio * URL : https://github.com/pytorch/audio * License : bsd-2 Programming Lang: py Description : Data manipulation and transformation for audio signal processing, powered by PyTorch enables user to manipulate audio data using pytorch debian deep learning team
Bug#958891: ITP: pytorch-text -- Data loaders and abstractions for text and NLP
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pytorch-text * URL : https://github.com/pytorch/text * License : bsd-3 Programming Lang: py Description : Data loaders and abstractions for text and NLP allows users to better manipulate textual data using pytorch debian deep learning team
Bug#958888: ITP: pytorch -- Tensors and Dynamic neural networks in Python with strong GPU acceleration
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pytorch * URL : https://github.com/pytorch/pytorch * License : BSD-3 Programming Lang: C++, python Description : Tensors and Dynamic neural networks in Python with strong GPU acceleration One of the top-2 deep learning frameworks I've uploaded all the necessary build dependencies to the NEW queue. Now I'm waiting for the upstream to merge my pull requests. will be maintained under Debian Deep Learning Team
Bug#958818: ITP: xnnpack -- High-efficiency floating-point neural network inference operators for mobile, server, and Web
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: xnnpack * URL : https://github.com/google/XNNPACK * License : BSD_3 Programming Lang: C++ Description : High-efficiency floating-point neural network inference operators for mobile, server, and Web optional pytorch dependency debian deep learning team
Bug#958655: ITP: pthreadpool -- pthread-based thread pool for C/C++
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pthreadpool * URL : https://github.com/Maratyszcza/pthreadpool * License : BSD-2 Programming Lang: C++/C Description : pthread-based thread pool for C/C++ pytorch dependency debian deep learning team
Bug#958654: ITP: psimd -- Portable 128-bit SIMD intrinsics
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: psimd * URL : https://github.com/Maratyszcza/psimd * License : MIT Programming Lang: C++ Description : Portable 128-bit SIMD intrinsics pytorch dependency debian deep learning team
Bug#958653: ITP: ideep -- Chainer module providing numpy like API and DNN acceleration using MKL-DNN
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: ideep * URL : https://github.com/intel/ideep * License : MIT Programming Lang: C++ Description : Chainer module providing numpy like API and DNN acceleration using MKL-DNN pytorch(caffe2) dependency debian deep learning team
Bug#958652: ITP: foxi -- ONNXIFI with Facebook Extension
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: foxi * URL : https://github.com/houseroad/foxi/ * License : MIT Programming Lang: C Description : ONNXIFI with Facebook Extension pytorch(caffe2) dependency debian deep learning team
Bug#958650: ITP: fp16 -- Conversion to/from half-precision floating point formats
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: fp16 * URL : https://github.com/Maratyszcza/FP16 * License : MIT Programming Lang: C++ Description : Conversion to/from half-precision floating point formats pytorch dependency debian deep learning team
Bug#958651: ITP: fxdiv -- C99/C++ header-only library for division via fixed-point multiplication by inverse
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: fxdiv * URL : https://github.com/Maratyszcza/FXDiv * License : MIT Programming Lang: C++ Description : C99/C++ header-only library for division via fixed-point multiplication by inverse pytorch dependency debian deep learning team
Bug#958517: ITP: rabit -- Reliable Allreduce and Broadcast Interface for distributed machine learning
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: rabit * URL : https://github.com/dmlc/rabit/ * License : BSD-3 Programming Lang: C++ Description : Reliable Allreduce and Broadcast Interface for distributed machine learning xgboost dependency maintained under deep learning team
Bug#958516: ITP: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: asmjit * URL : https://github.com/asmjit/asmjit * License : Zlib license Programming Lang: X++ Description : Complete x86/x64 JIT and AOT Assembler for C++. pytorch dependency. will be maintained under deep learning team.
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
On Thu, Apr 16, 2020 at 03:40:09PM +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > Control: tags 956889 + moreinfo > > On Thu, 2020-04-16 at 11:26 +0000, Mo Zhou wrote: > > (please explain the reason for this update here) > > > > We need to cherry-pick two patches in order to fix a deadlock issue > > for zfs > > https://github.com/openzfs/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d > > https://github.com/openzfs/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a > > > > And the two patches have to be used in conjunction with a patch for > > src:spl-linux > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932251 > > (I'm uploading shortly) > > I'm afraid I'm slightly confused here. > > You've filed two copies of this bug, with slightly different content. Please ignore the result of a mutt crash. > Neither of them has a proposed diff attached, and they both claim to be see attached debdiff. > requesting updates for the "zfs-linux" package, but the upload you've > made is for the "spl-linux" package, for which there appears to be no > p-u bug. The whole fix involes two parts: a part goes to src:zfs-linux and the other goes to src:spl-linux. Now that the updated src:spl-linux is already uploaded, and I'm now asking for the permission to upload the updated src:zfs-linux. Which includes two upstream commits fixing potential deadlock issues. > Please could you clarify? > > Regards, > > Adam > diff -Nru zfs-linux-0.7.12/debian/changelog zfs-linux-0.7.12/debian/changelog --- zfs-linux-0.7.12/debian/changelog 2019-06-09 11:17:40.0 +0800 +++ zfs-linux-0.7.12/debian/changelog 2020-04-22 13:14:27.0 +0800 @@ -1,3 +1,11 @@ +zfs-linux (0.7.12-2+deb10u2) buster; urgency=medium + + * Cherry-pick two upstream patches to fix potential deadlock issues. ++ 01937958ce85b1cd8942dbaf9a3f9768c5b02a0a ++ 98bb45e27ae80145a6ce028df90fccdb23f8901d + + -- Mo Zhou Wed, 22 Apr 2020 13:14:27 +0800 + zfs-linux (0.7.12-2+deb10u1) testing-proposed-updates; urgency=high * Patch: Disable SIMD on 4.19.37+ or 5.0+ kernels. (Closes: #929929) diff -Nru zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch --- zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch 1970-01-01 08:00:00.0 +0800 +++ zfs-linux-0.7.12/debian/patches/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a.patch 2020-04-22 13:11:49.0 +0800 @@ -0,0 +1,327 @@ +From 01937958ce85b1cd8942dbaf9a3f9768c5b02a0a Mon Sep 17 00:00:00 2001 +From: Matthew Ahrens +Date: Thu, 31 May 2018 10:29:12 -0700 +Subject: [PATCH] OpenZFS 9577 - remove zfs_dbuf_evict_key tsd + +The zfs_dbuf_evict_key TSD (thread-specific data) is not necessary - +we can instead pass a flag down in a few places to prevent recursive +dbuf eviction. Making this change has 3 benefits: + +1. The code semantics are easier to understand. +2. On Linux, performance is improved, because creating/removing + TSD values (by setting to NULL vs non-NULL) is expensive, and + we do it very often. +3. According to Nexenta, the current semantics can cause a + deadlock when concurrently calling dmu_objset_evict_dbufs() + (which is rare today, but they are working on a "parallel + unmount" change that triggers this more easily): + +Porting Notes: +* Minor conflict with OpenZFS 9337 which has not yet been ported. + +Authored by: Matthew Ahrens +Reviewed by: George Wilson +Reviewed by: Serapheim Dimitropoulos +Reviewed by: Brad Lewis +Reviewed-by: George Melikov +Ported-by: Brian Behlendorf + +OpenZFS-issue: https://illumos.org/issues/9577 +OpenZFS-commit: https://github.com/openzfs/openzfs/pull/645 +External-issue: DLPX-58547 +Closes #7602 +--- + include/sys/dbuf.h | 4 +-- + include/sys/dnode.h | 4 +-- + module/zfs/dbuf.c | 69 ++--- + module/zfs/dnode.c | 7 +++-- + module/zfs/dnode_sync.c | 17 -- + 5 files changed, 46 insertions(+), 55 deletions(-) + +diff --git a/include/sys/dbuf.h b/include/sys/dbuf.h +index 127acad33c7..e007e97644e 100644 +--- a/include/sys/dbuf.h b/include/sys/dbuf.h +@@ -20,7 +20,7 @@ + */ + /* + * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. +- * Copyright (c) 2012, 2015 by Delphix. All rights reserved. ++ * Copyright (c) 2012, 2018 by Delphix. All rights reserved. + * Copyright (c) 2013 by Saso Kiselkov. All rights reserved. + * Copyright (c) 2014 Spectra Logic Corporation, All rights reserved. + */ +@@ -294,7 +294,7 @@ boolean_t dbuf_try_add_ref(dmu_buf_t *db, objset_t *os, uint64_t obj, + uint64_t dbuf_refcount(dmu_buf_impl_t *db); + + void dbuf_rele(dmu_buf_impl_t *db, void *tag); +-void dbuf_rele_and_unlock(dmu_buf_impl_t *db, void *t
Bug#958294: ITP: dmlc-core -- A common bricks library for building scalable and portable distributed machine learning.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: dmlc-core * URL : https://github.com/dmlc/dmlc-core/ * License : Apache-2.0 Programming Lang: C++ Description : A common bricks library for building scalable and portable distributed machine learning. under deep learning team.
Bug#958072: ITP: xgboost -- Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: xgboost * URL : https://github.com/dmlc/xgboost * License : Apache-2 Programming Lang: C++, Pyhton Description : Scalable, Portable and Distributed Gradient Boosting (GBDT, GBRT or GBM) Library Useful for the data science community. Will be maintained under the debian deeplearning team.
Bug#956889: Acknowledgement (buster-pu: package zfs-linux/0.7.12-2+deb10u2)
Control: close -1 This bug is duplicated with #956889. When sending this mail for the first time my mutt crashed somehow. Hence the duplicated submission. On Thu, Apr 16, 2020 at 11:27:04AM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 956889: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956889. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Release Team > > If you wish to submit further information on this problem, please > send it to 956...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 956889: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956889 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#956890: buster-pu: package zfs-linux/0.7.12-2+deb10u2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu (please explain the reason for this update here) We need to cherry-pick two patches in order to fix a deadlock issue for zfs https://github.com/openzfs/zfs/commit/98bb45e27ae80145a6ce028df90fccdb23f8901d https://github.com/openzfs/zfs/commit/01937958ce85b1cd8942dbaf9a3f9768c5b02a0a And the two patches have to be used in conjunction with a patch for src:spl-linux https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932251 (I'm uploading shortly) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
