Bug#919570: ITP: python-mypy-extensions -- Experimental type system extensions for mypy typechecker (Python 3)
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: python-mypy-extensions Version : 0.4.1 Upstream Author : Jukka Lehtosalo and contributors * URL : https://github.com/python/mypy_extensions/ * License : Expat Programming Lang: Python Description : Experimental type system extensions for mypy typechecker (Python 3) (Include the long description here. Add type annotations to your Python programs, and use mypy to type check them. Mypy is essentially a Python linter on steroids, and it can catch many programming errors by analyzing your program, without actually having to run it. Mypy has a powerful type system with features such as type inference, gradual typing, generics and union types. . The "mypy_extensions" module defines experimental extensions to the standard "typing" module that are supported by the mypy typechecker. . This package provides the modules for Python 3. This python module was previously part of the python3-mypy binary package from the mypy source package as it came from the same PyPI source distribution. Now it has been split into its own sdist/GitHub repo as of mypy v 0.660, so this separate package is needed. As with mypy, python-mypy-extensions will be team maintained by Debian Med.
Re: Google Summer of Code 2019
Hello > > Please remember that our rules for GSoC projects changed a bit [3]. Debian > is no longer > an umbrella organisation, which means that every project needs to be > related > directly to Debian. Every project should also have at least one mentor that > is already known in our community. > > This is very good step. Big thanks for this. regards deepanshu
ITP: imapsync -- Email IMAP tool for syncing, and migrating email mailboxes between two imap servers, one way, and without duplicates.
Package: wnpp Owner: "M.Raps" Severity: wishlist * Package name : imapsync Version 1.882 Upstream Author : Gilles Lamiral * URL : https://github.com/imapsync/imapsync * License : NLPL Programming Lang: Perl Description : Email IMAP tool for syncing, copying and migrating email mailboxes between two imap servers, one way, and without duplicates. i missing this master piece of software in debian, since i started my admin career. a couple years ago, the upstream Author played with licensing and payment around but now its free again. https://lists.debian.org/debian-user/2018/11/msg00849.html i already migrated tons of mails with it and i think a lot of mailadmins would benefit from it to see this package back in debian.
Re: Bug#919587: ITP: imapsync -- Email IMAP tool for syncing, and migrating email mailboxes between two imap servers, one way, and without duplicates.
wrong link: https://lists.debian.org/debian-user/2016/11/msg00849.html
confused about virtual build-depends libcurl-dev
We're trying to package nix. Its d/control[1] currently says: build-depends: libcurl4-gnutls-dev | libcurl4-openssl-dev | libcurl-ssl-dev When I build it on my own machines with sbuild, then it gets built with libcurl4-gnutls-dev. On salsa it gets built with libcurl4-nss-dev. How can there be a difference in selection? Why would I want to leave the selection of the build dependency open? Remarks: - https://www.debian.org/doc/debian-policy/ch-binary.html#virtual-packages links to virtual-package-names-list.yaml instead of .txt. - The virtual-package-names-list.txt does not contain "libcurl". Thank you! [1] https://salsa.debian.org/debian/nix/blob/kaiha/wip/debian/control
Re: confused about virtual build-depends libcurl-dev
On Thu, 17 Jan 2019 at 21:29:58 +0100, Thomas Koch wrote: > We're trying to package nix. Its d/control[1] currently says: > > build-depends: libcurl4-gnutls-dev | libcurl4-openssl-dev | libcurl-ssl-dev > > When I build it on my own machines with sbuild, then it gets built with > libcurl4-gnutls-dev. On salsa it gets built with libcurl4-nss-dev. How can > there be a difference in selection? If the build environment (chroot? container? VM? whatever it is) already has a different implementation installed, you'll get that one. sbuild specifically doesn't respect alternative build dependencies and only takes the first one, in an attempt to make builds more deterministic. > Why would I want to leave the selection of the build dependency open? If you're building in a shared container/chroot/VM/thing that has some packages installed already, you might not be able to make a free choice of what to install: if you have a package that can use any flavour of libcurl, and a different package that specifically needs the OpenSSL flavour, and they need to build in the same container/chroot/VM/thing, then you'll have to use the OpenSSL flavour for both (because they aren't co-installable). > - The virtual-package-names-list.txt does not contain "libcurl". Presumably the users of libcurl are either "a cooperating group of packages" (Policy §3.6), or non-Policy-compliant. smcv
Work-needing packages report for Jan 18, 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: 1338 (new: 10) Total number of packages offered up for adoption: 154 (new: 2) Total number of packages requested help for: 57 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: farmhash (#919550), orphaned today Description: FarmHash, a family of hash functions Reverse Depends: libfarmhash-dev Installations reported by Popcon: 5 Bug Report URL: https://bugs.debian.org/919550 gemmlowp (#919551), orphaned today Description: small self-contained low-precision GEMM library Installations reported by Popcon: 2 Bug Report URL: https://bugs.debian.org/919551 highwayhash (#919552), orphaned today Description: Fast strong hash functions: SipHash/HighwayHash Reverse Depends: libhighwayhash-dev Installations reported by Popcon: 7 Bug Report URL: https://bugs.debian.org/919552 irqbalance (#919261), orphaned 3 days ago Description: Daemon to balance interrupts for SMP systems Installations reported by Popcon: 98523 Bug Report URL: https://bugs.debian.org/919261 linuxbrew-wrapper (#919039), orphaned 5 days ago Description: Homebrew package manager for Linux Installations reported by Popcon: 49 Bug Report URL: https://bugs.debian.org/919039 nsync (#919553), orphaned today Description: C library that exports various synchronization primitives Reverse Depends: libnsync-dev Installations reported by Popcon: 5 Bug Report URL: https://bugs.debian.org/919553 ujson (#919485), orphaned yesterday Reverse Depends: hinge python-gnocchiclient python-ujson-dbg python3-gnocchi python3-gnocchiclient python3-ujson-dbg Installations reported by Popcon: 85 Bug Report URL: https://bugs.debian.org/919485 wmxres (#919163), orphaned 4 days ago Description: dock application to select your display mode among those possible Installations reported by Popcon: 31 Bug Report URL: https://bugs.debian.org/919163 yamdi (#919164), orphaned 4 days ago Description: a utility for adding metadata to flash video files Installations reported by Popcon: 50 Bug Report URL: https://bugs.debian.org/919164 zeitgeist (#919274), orphaned 3 days ago Description: event logging framework Reverse Depends: activity-log-manager cairo-dock-recent-events-plug-in diodon gedit-plugin-dashboard gedit-plugin-zeitgeist gir1.2-zeitgeist-2.0 libdiodon0 libfolks-telepathy25 libzeitgeist-2.0-dev rhythmbox-plugins (6 more omitted) Installations reported by Popcon: 59478 Bug Report URL: https://bugs.debian.org/919274 1328 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: nethack-el (#919542), offered today Description: Emacs major-mode for playing NetHack Installations reported by Popcon: 58 Bug Report URL: https://bugs.debian.org/919542 xloadimage (#919265), offered 3 days ago Description: Graphics file viewer under X11 Installations reported by Popcon: 1515 Bug Report URL: https://bugs.debian.org/919265 152 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 778 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: autodeb-worker debci-worker Installations reported by Popcon: 1176 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 2671 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 684 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 374 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1883 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 646 days ago Description: Rust package manager Reverse Depends: cargo-vendor dh-cargo Installations reported by Popcon: 837 Bug Report URL: https://bugs.debian.org/860116 cyrus-sasl2 (#799864), requested 1212 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-ma
Re: Conflict over /usr/bin/dune
On Tue, 18 Dec 2018 17:48:06 + Ian Jackson
wrote:
> Ian Jackson writes ("Re: Conflict over /usr/bin/dune"):
> > https://www.google.com/search?q=dune+software
> > https://en.wikipedia.org/wiki/Dune_(software)
> > https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
> >
> > Under the circumstances it seems obvious that, at the very least, the
> > ocaml build tool should not be allowed the name /usr/bin/dune.
>
> Perhaps I should have stated this explicitly, since it was not obvious
> unless you follow the links.
>
> `Dune' is not, as a piece of software, primarily either the ocaml
> build tool, or the 3D modeller.
>
> Mostly it is DUNE, a "modular C++ library for the solution of partial
> differential equations using grid-based methods". That's what you get
> if you visit the Wikipedia link I provided - not even a disambiguation
> link. The others don't rate a mention.
That C++ library is also something I was expecting to have this
(meta-)package called dune.
If the ocaml build system wants to stay within the theme, what about
"camel" ? And once they find out that there is already camel.apache.org,
rename it again to "hump" (which seems to be available).
Andreas
Bug#919624: ITP: daps -- DocBook-based authoring and publishing system
Package: wnpp Severity: wishlist Owner: Filippo Rusconi * Package name: daps Version : 3.0.0 Upstream Author : Frank Sundermeyer * URL : http://opensuse.github.io/daps * License : GPL-3.0 Programming Lang: Shell, Python Description: DocBook Authoring and Publishing Suite (DAPS) DAPS contains a set of stylesheets, scripts and makefiles that enable you to create HTML, PDF, EPUB and other formats from DocBook XML with a single command. It also contains tools to generate profiled source tarballs for distributing your XML sources for translation or review. . DAPS also includes tools that assist you when writing DocBook XML: linkchecker, validator, spellchecker, editor macros and stylesheets for converting DocBook XML. I was looking for some integrated solution to author the user manuals of my msXpertSuite software and I tried publican, but felt it was a bit rough. Then I discovered daps and I found it really well documented, really well-functioning. In no time I had a workflow that worked flawlessly. DocBook is now getting more and more traction even amongs non-technical writers. I feel that having a bit of competition in Debian is useful. When DAPS will be in Debian, I'll build the user manuals of mineXpert and massXpert during package build. Thanks Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Scientist at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org
Re: confused about virtual build-depends libcurl-dev
Thomas Koch wrote: > We're trying to package nix. Its d/control[1] currently says: > build-depends: libcurl4-gnutls-dev | libcurl4-openssl-dev | libcurl-ssl-dev > When I build it on my own machines with sbuild, then it gets built > with libcurl4-gnutls-dev. On salsa it gets built with > libcurl4-nss-dev. How can there be a difference in selection? I am the one responsible for a change in the build-depdendency resolver used by the Salsa-CI pipelines. Before the change, they used "apt-get build-dep ." to gather the build-deps, but this didn't work for *-backports or experimental or Jessie. Also it would pull in recommended packages, which could make the build unreproducible and is agains Policy 4.2. I changed the resolver to use a combination of mk-build-deps and aptitude, the same as sbuild and pbuilder use to resolve build-deps, to better handle alternatives. You may have hid an edge case I didn't encounter during my testing. > [1] https://salsa.debian.org/debian/nix/blob/kaiha/wip/debian/control Do you have a pipeline log on Salsa showing the mis-selection of build-deps? During a cursory glance I could only find logs showing the use of libcurl4-gnutls-dev. Grüße, Sven. -- Sigmentation fault. Core dumped.
