Work-needing packages report for Sep 6, 2019
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1326 (new: 9) Total number of packages offered up for adoption: 157 (new: 1) Total number of packages requested help for: 53 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: editmoin (#939054), orphaned 5 days ago Description: edit MoinMoin wiki pages with your favourite editor Installations reported by Popcon: 40 Bug Report URL: https://bugs.debian.org/939054 flowscan (#939422), orphaned yesterday Description: flow-based IP traffic analysis and visualization tool Reverse Depends: flowscan-cuflow Installations reported by Popcon: 50 Bug Report URL: https://bugs.debian.org/939422 freedink (#938934), orphaned 6 days ago Description: humorous top-down adventure and role-playing game Reverse Depends: freedink Installations reported by Popcon: 252 Bug Report URL: https://bugs.debian.org/938934 freedink-data (#938935), orphaned 6 days ago Description: adventure and role-playing game (assets) Reverse Depends: freedink-engine Installations reported by Popcon: 253 Bug Report URL: https://bugs.debian.org/938935 freedink-dfarc (#938937), orphaned 6 days ago Description: frontend and .dmod installer for GNU FreeDink Reverse Depends: freedink freedink-dfarc-dbg Installations reported by Popcon: 251 Bug Report URL: https://bugs.debian.org/938937 gdisk (#939421), orphaned yesterday Description: GPT fdisk text-mode partitioning tool Reverse Depends: ceph-base clonezilla cloud-init debootstick forensics-extra libblockdev-part2 libguestfs0 linaro-image-tools tails-installer Installations reported by Popcon: 103142 Bug Report URL: https://bugs.debian.org/939421 golang-github-docopt-docopt-go (#939018), orphaned 5 days ago Description: implementation of docopt in the Go programming language Reverse Depends: golang-github-anacrolix-missinggo-dev golang-github-googleapis-gnostic-dev Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/939018 paexec (#939228), orphaned 3 days ago Description: execute tasks in parallel Installations reported by Popcon: 8 Bug Report URL: https://bugs.debian.org/939228 rsnapshot (#939427), orphaned yesterday Description: local and remote filesystem snapshot utility Installations reported by Popcon: 2348 Bug Report URL: https://bugs.debian.org/939427 1317 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: inspircd (#939424), offered yesterday Description: Modular IRCd written in C++ Installations reported by Popcon: 68 Bug Report URL: https://bugs.debian.org/939424 156 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 1009 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1197 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2902 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 731 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 605 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1760 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 877 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1171 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1443 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-legacy-tools 389-ds-base-libs adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (109 more omitted) Installations reported by Popcon: 197314 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1147 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installatio
Bug#939517: ITP: pkgtop -- Interactive package manager and resource monitor designed for the GNU/Linux.
Package: wnpp Severity: wishlist Owner: keylo99 * Package name: pkgtop Version : 1.8-1 Upstream Author : k3 * URL : https://github.com/keylo99/pkgtop * License : GPL-3.0 Programming Lang: Go Description : Interactive package manager and resource monitor designed for the GNU/Linux. pkgtop . pkgtop is an interactive package manager & resource monitor tool designed for the GNU/Linux. . Package management (install/upgrade/remove etc.) can be a problem if the user is not familiar with the operating system or the required command for that operation. So pkgtop tries to solve this problem with an easy-to-use terminal interface and shortcut keys. Briefly, pkgtop aims to provide a terminal dashboard for managing packages on GNU/Linux systems. Using the terminal dashboard, it's possible to list installed packages by size (or alphabetically with -a argument), show information about the package, install/upgrade/remove packages and search package. Also, there are other handy shortcuts for easing the package management process which mentioned in the usage information (https://github.com/keylo99/pkgtop#usage). . License GNU General Public License v3. (see gpl (https://www.gnu.org/licenses/gpl.txt)) Credit Copyright (C) 2019 by keylo99 (https://www.github.com/keylo99)
Re: On the Removal of src:tensorflow
> "Mo" == Mo Zhou writes: Mo> Hi Steffen, I'm wondering who will read it. In the past I Mo> broadcasted some bits I learned to the public mailing lists and Mo> people responded, but nobody had ever asked me any detail about Mo> anything related. I think a lot of us have read this and filed it away. Right now, I think that there are a few people in Debian who have been following the issues closely who may be around the same level you are. And there are a lot of us who have read this, filed it away, and six months to yearsfrom now will be reading it again and having questions when we run across something in the deep learning space.
Re: On the Removal of src:tensorflow [and 1 more messages]
On 2019-09-05 11:31, Ian Jackson wrote:
> Mo Zhou writes ("Re: On the Removal of src:tensorflow [and 1 more messages]"):
>
> ... when you have done this please let me know and I will make a wiki
> page at least referencing your document(s), and maybe summarisig.
Look forward to collaborating with you and porting/linking the WIP
document to debian wiki.
> If you could arrange to mirror your article on some Debian server that
> would avoid possible future linkrot (although if you plan for your own
> article to have a good longterm stable url then maybe that's not
> needed).
Take it easy. I'm a sane upstream. The source will be available
on salsa, released under CC-BY-SA-4.0 license, and the compiled
format (maybe pdf) will be uploaded to people.d.o .
Re: On the Removal of src:tensorflow
On 2019-09-05 10:44, Jonathan Carter wrote: > On 2019/09/05 05:55, Yao Wei wrote: > I filed it and intend to keep it open for the foreseeable future. Based > on Mo's original post in this thread, I decided that it will be better > to look for alternatives to DeepSpeech (especially since all my intended > use cases rely on very limited dictionaries). The horrible fact is that one cannot find any decent alternative to deep learning, especially on the problems impossible for a non-intelligent algorithm to solve. There are countless examples about things that only deep learning could solve (traditional machine learning could solve a portion of them but generally deep learning does the best). For ASR (Automatic Speech Recognition) you will find nothing except for deep learning among the best implementations. Traditional models for ASR, such as HMM (hidden markov chain) are just far less accurate compared to deep learning, as reported by papers. One day ML-Policy will eventually show its sanity. > Things change though and the Tensorflow project might mature in a few > years and the project might have better methods available for building it. Tensorflow 1.X is a long-term support release and it's basically mature enough. It will be maintained for a while even after the 2.X release. An energetic developer could work on the abandoned cmake build and produce packages enough for supporting applications such as deepspeech. > I think a link to Mo's mail is sufficient on the DeepSpeech ITP bug > report (and related ITPs). Less is probably more when it comes to wiki > pages at this point. :-)
Re: On the Removal of src:tensorflow [and 1 more messages]
Mo Zhou writes ("Re: On the Removal of src:tensorflow [and 1 more messages]"):
> Thanks for the offering. I'm not eager to write such a wiki page
> because it's not urgent. Plus, currently I have a rather complete
> image on the "Future Debian and Artificial Intelligence" topic
> based on experience. Of course I won't be satisfied by
> only documenting these small points.
OK, fair enough. How about this
> I've already planned to write a long article on the whole topic
> with a good overview and some important details[1] including
> those mentioned in the previous mails. Please look forward to it.
> After finishing the article, porting it to debian wiki would be
> trivial enough.
... when you have done this please let me know and I will make a wiki
page at least referencing your document(s), and maybe summarisig.
If you could arrange to mirror your article on some Debian server that
would avoid possible future linkrot (although if you plan for your own
article to have a good longterm stable url then maybe that's not
needed).
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: On the Removal of src:tensorflow [and 1 more messages]
Hi Ian,
Thanks for the offering. I'm not eager to write such a wiki page
because it's not urgent. Plus, currently I have a rather complete
image on the "Future Debian and Artificial Intelligence" topic
based on experience. Of course I won't be satisfied by
only documenting these small points.
I've already planned to write a long article on the whole topic
with a good overview and some important details[1] including
those mentioned in the previous mails. Please look forward to it.
After finishing the article, porting it to debian wiki would be
trivial enough.
On the other hand, rushing a debian wiki page covering only a
single small topic, out of git tracking, would result in something
like "write once, burden forever" to me once the URL had been
widely spread. So please wait for my article.
P.S.
I'm concurrently working on 3 non-trivial documentation projects:
1. "Debian and Gentoo's Linear Algebra Libraries" (i.e. BLAS/LAPACK)
2. The Unofficial "ML-Policy"
3. "Future Debian and Artificial Intelligence"
hope this could help me demonstrate how unwilling I am to
maintain a wiki page.
[1] and possibly submit it to lwn
On 2019-09-05 08:23, Ian Jackson wrote:
> Jonas Smedegaard writes ("Re: On the Removal of src:tensorflow"):
>> Please beware that there's a huge difference between being able to
>> stumble upon your notes in a web search - and in the case of a wiki page
>> to add additional notes to it - and then to have an open invitation to
>> ask questions to an expert.
>>
>> I encourage you to help get your valuable information onto our wiki,
>> regardless of the lack of feedback you have received on it.
>
> Seconded. However, I don't think this...
>
>> Our wiki does not use mediawiki but an older(?) markup called Creole.
>
> Mo Zhou writes ("Re: On the Removal of src:tensorflow"):
>> I dislike the mediawiki markup. [...]
>
> ... is likely to be an answer to that.
>
> Mo: if you write up your notes in some plain text format I will put
> them on the wiki for you. You should probably do that by replying to
> this thread because of the principle of doing things in public.
> Please be sure to CC me on the email. NB that do *not* intend to take
> on the role of ongoing document editor and won't be incorporating
> comments made in response to your mail.
>
> Thanks,
> Ian.
Re: On the Removal of src:tensorflow
On 2019/09/05 05:55, Yao Wei wrote: > On Wed, Sep 04, 2019 at 07:38:11PM -0700, Mo Zhou wrote: >> I'm wondering who will read it. In the past I broadcasted some bits >> I learned to the public mailing lists and people responded, but >> nobody had ever asked me any detail about anything related. > > Recently there's ITP for DeepSpeech (#921519) based on Baidu's research > and Mozilla Common Voice project, which is depending on TensorFlow: > > https://github.com/mozilla/DeepSpeech I filed it and intend to keep it open for the foreseeable future. Based on Mo's original post in this thread, I decided that it will be better to look for alternatives to DeepSpeech (especially since all my intended use cases rely on very limited dictionaries). Things change though and the Tensorflow project might mature in a few years and the project might have better methods available for building it. > I think it is a good practice to leave a tombstone in the wiki that what > you consider may be pitfalls for packaging deep learning programs and > the problems that are specific to certain ML frameworks. > > If anyone wants to resurrect TensorFlow in Debian, then it is a good > reference to see what they would like to avoid. I think a link to Mo's mail is sufficient on the DeepSpeech ITP bug report (and related ITPs). Less is probably more when it comes to wiki pages at this point. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool
Quoting Simon Richter (2019-09-05 12:05:40) > On Wed, Sep 04, 2019 at 09:24:31PM +0200, g...@iroqwa.org wrote: > > > I intend to orphan the gdisk package. > > > The package description is: > > GPT fdisk (aka gdisk) is a text-mode partitioning > > tool that works on Globally Unique Identifier > > (GUID) Partition Table (GPT) disks, rather than > > on the more common (through 2009) > > Master Boot Record (MBR) partition tables. > > I believe this can be safely removed. The fdisk program has gained GPT > support since gdisk was written, so a separate tool is no longer > needed. Please don't drop gdisk - it has special features not found in other tools, e.g. for migrating between formats and creating "hybrid" MBRs: See its manpage about the "recovery & transformation menu". If noone else steps up, I might look after it, but I prefer if someone else does it (I have my hands full already). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool
On 2019/09/05 12:05, Simon Richter wrote: > I believe this can be safely removed. The fdisk program has gained GPT > support since gdisk was written, so a separate tool is no longer needed. I'm not sure they have feature parity, I've had to help a lot of people who had strange partition layouts (hybrid MBR/GPT) that was misconfigured, often on low-end Acer and HP laptops, and very often on refurbished laptops that were re-installed (or rather, imaged) with Windows on them, and the only tool that (I know of) that could fix these to reliably dual-boot these setups with Debian is gdisk. It allows you to convert between GPT and MBR, backup/restore your current layout easily or to set up a proper hybrid system (if you need it for whatever reason, Windows doesn't like changes). AFAIK fdisk doesn't let you do all of this yet. If I'm correct and fdisk does indeed not let you do that then I'd rather maintain gdisk than have it removed from the archives since I somewhat rely on it for some of my users who have crappy^W more lower-end laptops. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool
Hi, On Wed, Sep 04, 2019 at 09:24:31PM +0200, g...@iroqwa.org wrote: > I intend to orphan the gdisk package. > The package description is: > GPT fdisk (aka gdisk) is a text-mode partitioning > tool that works on Globally Unique Identifier > (GUID) Partition Table (GPT) disks, rather than > on the more common (through 2009) > Master Boot Record (MBR) partition tables. I believe this can be safely removed. The fdisk program has gained GPT support since gdisk was written, so a separate tool is no longer needed. Simon
Bug#939465: ITP: python-virustotal-api -- Virus Total Public/Private/Intel API for Python
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-virustotal-api Version : 1.1.10 Upstream Author : blacktop (https://github.com/blacktop) * URL : https://github.com/blacktop/virustotal-api * License : MIT Programming Lang: Python Description : Virus Total Public/Private/Intel API for Python This package contains Python 3 API bindings for VirusTotal's public, private and intelligence APIs. The VirusTotal API lets you upload and scan files or URLs, access finished scan reports and make automatic comments without the need of using the website interface. The VirusTotal Intelligence API exposes some VirusTotal Intelligence functionality for programmatic interaction, such as working with Hunting rulesets, automating notifications, and automating file searches and downloads.
Bug#939464: ITP: python-oletools -- Python tools to analyze MS OLE2 files
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: python-oletools Version : 0.04 Upstream Author : Philippe Lagadec * URL : http://www.decalage.info/python/oletools * License : BSD Programming Lang: Python Description : Python tools to analyze MS OLE2 files python-oletools is a package of Python tools to analyze Microsoft OLE2 files (also called Structured Storage, Compound File Binary Format or Compound Document File Format), such as Microsoft Office documents or Outlook messages, mainly for malware analysis and debugging. It is based on the OleFileIO_PL parser. It is not related to OLETools published by BeCubed Software.
Re: On the Removal of src:tensorflow [and 1 more messages]
Jonas Smedegaard writes ("Re: On the Removal of src:tensorflow"):
> Please beware that there's a huge difference between being able to
> stumble upon your notes in a web search - and in the case of a wiki page
> to add additional notes to it - and then to have an open invitation to
> ask questions to an expert.
>
> I encourage you to help get your valuable information onto our wiki,
> regardless of the lack of feedback you have received on it.
Seconded. However, I don't think this...
> Our wiki does not use mediawiki but an older(?) markup called Creole.
Mo Zhou writes ("Re: On the Removal of src:tensorflow"):
> I dislike the mediawiki markup. [...]
... is likely to be an answer to that.
Mo: if you write up your notes in some plain text format I will put
them on the wiki for you. You should probably do that by replying to
this thread because of the principle of doing things in public.
Please be sure to CC me on the email. NB that do *not* intend to take
on the role of ongoing document editor and won't be incorporating
comments made in response to your mail.
Thanks,
Ian.
Re: Clarification regarding Qt 4 removal (and #875036 in particular)
Hi Gard On Thu, Sep 05, 2019 at 09:36:01AM +0200, Gard Spreemann wrote: > Can someone help clarify why the Qt 4 removal causes all of > src:libqglviewer to be marked for removal? Surely its Qt 5 binaries > could stay? Sure, but it also builds Qt 4 binaries, which can't stay. So someone needs to remove them. > Is there any course of action I should take as maintainer of gudhi? I > tried contacting the maintainer of libqglviewer a few weeks ago, but got > no reply. https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu Please ask on debian-mentors for help. Regards, Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: Clarification regarding Qt 4 removal (and #875036 in particular)
Scott Kitterman writes: > On September 5, 2019 7:36:01 AM UTC, Gard Spreemann wrote: >>Can someone help clarify why the Qt 4 removal causes all of >>src:libqglviewer to be marked for removal? Surely its Qt 5 binaries >>could stay? > > All binaries from a source package are removed as a set, so if the Qt4 > packages are RC buggy, they all have to go. Ah, of course, that makes sense. Thanks. >>Is there any course of action I should take as maintainer of gudhi? I >>tried contacting the maintainer of libqglviewer a few weeks ago, but >>got >>no reply. > > You might investigate if there are remaining rdepends for the Qt4 > packages and if not, an NMU to drop them might be in order if you > continue not to hear from the maintainer. I see. The problem with that is I'm only a DM with uploading rights for a few packages. I'll try to contact the last uploader as well. Best, Gard
Re: Clarification regarding Qt 4 removal (and #875036 in particular)
On September 5, 2019 7:36:01 AM UTC, Gard Spreemann wrote: >Hi, > >I maintain src:gudhi, which build-depends on libqglviewer-dev-qt5 and >depends on libqglviewer2-qt5. Because of the Qt 4 removal, >src:libqglviewer, which provides the two aforementioned binaries, seems >to be marked for autoremoval (#875036), and thus src:gudhi too has been >marked for autoremoval according to the tracker. > >Can someone help clarify why the Qt 4 removal causes all of >src:libqglviewer to be marked for removal? Surely its Qt 5 binaries >could stay? All binaries from a source package are removed as a set, so if the Qt4 packages are RC buggy, they all have to go. >Is there any course of action I should take as maintainer of gudhi? I >tried contacting the maintainer of libqglviewer a few weeks ago, but >got >no reply. You might investigate if there are remaining rdepends for the Qt4 packages and if not, an NMU to drop them might be in order if you continue not to hear from the maintainer. Scott K
Re: On the Removal of src:tensorflow
Quoting Mo Zhou (2019-09-05 07:20:44) > > If anyone wants to resurrect TensorFlow in Debian, then it is a good > > reference to see what they would like to avoid. > > Anyone interested in this could ask me for hints if in need. Please beware that there's a huge difference between being able to stumble upon your notes in a web search - and in the case of a wiki page to add additional notes to it - and then to have an open invitation to ask questions to an expert. I encourage you to help get your valuable information onto our wiki, regardless of the lack of feedback you have received on it. Kind regards, from someone appreciating your work but not having much questions to ask, - Jonas P.S. Our wiki does not use mediawiki but an older(?) markup called Creole. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Clarification regarding Qt 4 removal (and #875036 in particular)
Hi, I maintain src:gudhi, which build-depends on libqglviewer-dev-qt5 and depends on libqglviewer2-qt5. Because of the Qt 4 removal, src:libqglviewer, which provides the two aforementioned binaries, seems to be marked for autoremoval (#875036), and thus src:gudhi too has been marked for autoremoval according to the tracker. Can someone help clarify why the Qt 4 removal causes all of src:libqglviewer to be marked for removal? Surely its Qt 5 binaries could stay? Is there any course of action I should take as maintainer of gudhi? I tried contacting the maintainer of libqglviewer a few weeks ago, but got no reply. Thanks for any pointers. Best, Gard
Bug#939451: ITP: nvidia-cub -- cooperative threadblock primitives and other utilities for CUDA kernel programming
Package: wnpp Severity: wishlist Owner: lu...@debian.org X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-nvidia-de...@lists.alioth.debian.org * Package name: nvidia-cub Version : x.y.z Upstream Author : nvidia * URL : https://nvlabs.github.io/cub/ * License : BSD-3-Clause Programming Lang: cuda, c++ Description : cooperative threadblock primitives and other utilities for CUDA kernel programming I've seen this many times in different projects e.g. https://github.com/tensorflow/tensorflow/tree/master/third_party https://github.com/pytorch/pytorch/tree/master/third_party https://github.com/mitsuba-renderer/enoki It's a sensible candidate to be packaged. The source code is free but it depends on cuda so the resulting package has to enter contrib.
