Bug#1004945: Please specify required version of Sphinx build-dep

> I think >= 3.5 should be enough It isn't. So we may as well go with bookworm's 4.3. Thanks again! -d

Bug#1004945: Please specify required version of Sphinx build-dep

Package: sqlalchemy Version: 1.4.23+ds1-5 Hello! To make the life of backporters slightly easier, could you please version your build-dependency on Sphinx? I think >= 3.5 should be enough: ``` dh_installdocs -O--buildsystem=pybuild debian/rules override_dh_sphinxdoc cd doc/build && python3 -m

Bug#968837: RFP: ruby-toys -- configurable command line tool for builds and workflows

Package: wnpp Severity: wishlist * Package name: ruby-toys Version : 0.11.0 Upstream Author : Daniel Azuma * URL : https://github.com/dazuma/toys * License : MIT Programming Lang: Ruby Description : configurable command line tool for builds and

Bug#919780: Please provide compatibility link under /usr/lib/rustlib/src

Package: rust-src Version: 1.31.0+dfsg1-2 Hello, It seems the default upstream install places its source files in /usr/lib/rustlib/src/rust/src (two "src", apparently), and many tools default to that path. It would be great (and very convenient) if the rust-src package could provide a

Bug#919761: Suggests context-doc-nonfree, which does not exist

Package: context Version: 2018.04.04.20181118-1 Suggested package context-doc-nonfree is not in buster, not unstable. Would be nice to drop the recommendation in the next upload. Thanks!

Bug#914568: emacs25: Please build with xwidget support

> check-security-status also says webkit2gtk is unsupported. So unless I > miss something, nothing has significantly changed with respect to > xwidgets. Okay, fair enough. It would still be nice, though, to have an emacs-xwidgets package. Unfortunately, it is not feasible to have it built in

Bug#906235: library documentation not included; HTML docs not well-formed

close 906235 close 906238 thanks > The HTML files included in the package are not well-formed and > do not include a header. This is because the docs are to be served via godoc only, as explained in the package description. I guess that description was there when I filed this, but I missed

Bug#917132: Do not compress favicon.ico file

Package: golang-1.11-doc Version: 1.11.2-2 Severity: minor The file: /usr/share/doc/golang-1.11-doc/favicon.ico.gz should not compressed, so that godoc can serve it. (After fixing that, the symlink at /usr/lib/go-1.11/favicon.ico.gz should be updated as well.) -d

Bug#916986: Downgrade hard-dependency on mailutils to recommends

Package: emacs Version: 1:26.1+1-2 It's nice that Emacs now uses secure tools for downloading e-mail, but the dependency on mailutils boils down to ~22 MiB of extra packages (that was in my case, considering I already had a MTA installed; mailutils depends on mail-transport-agent!) It would

Bug#911653: Please recommend or suggest the "nocache" package

Package: mlocate Version: 0.26-2 The daily cron script uses nocache if it's available. Since it's a useful addition, it would make sense for mlocate to recommend it. Thanks, -d

Bug#906238: HTML docs not well-formed, missing CSS and TOCs

Package: golang-doc The HTML files included in th epackage are not well-formed and do not include a header. For example, the file code.html starts: Introduction and does not include a table of contents, or CSS, as the online copy at [https://golang.org/doc/code.html] does. Many thanks for

Bug#906235: Library documentation not included

Package: golang-doc Severity: important I installed this package and golang-1.10-doc, and no documentation for the standard library was provided. I would expect the package to include all the documentation available at [https://golang.org/pkg/]. Many thanks in advance, -d

Bug#869030: elixir: Please package v1.4

retitle 869030 elixir: please package v1.6 thanks I would also love to see an updated Elixir in Debian, particularly now that v1.6 is released. If you don't have the time to do it, would you welcome some help in preparing the upload? -d

Bug#886449: Include HTML docs from tarball in libfuse-dev

Package: libfuse-dev Version: 2.9.7-1 Severity: wishlist It would be nice to have the ‘doc/html’ directory from the upstream tarball made available in /usr/share/doc/libfuse-dev/html. -d

Bug#873738: RFP: trepan3k -- a GDB-like debugger for Python

Package: wnpp Severity: wishlist * Package name: trepan3k * URL : https://pypi.python.org/pypi/trepan3k Upstream Author : Rocky Bernstein * License : GPL3 The original version for Python 2.7 is marked on PyPI as stable. This port for Python 3.x (by the same author) is

Bug#862050: New upstream bugfix release 25.2 available

Source: emacs25 Version: 25.1+1-4 Emacs 25.2 was released on April 22nd: [https://lists.gnu.org/archive/html/info-gnu/2017-04/msg9.html] It would be nice to have it available on unstable. -d

Bug#851596: closed by Norbert Preining <prein...@debian.org> (Bug#851596: fixed in maildir-utils 0.9.18-1)

Thanks for the prompt upload! Much appreciated. -d

Bug#851596: New stable release 0.9.18

Source: maildir-utils Version: 0.9.17-2 0.9.17 is a pre-release version that was allowed to migrate to testing. It would be better not to ship a pre-release version of mu in Debian stable. A stable version, 0.9.18, was released by upstream a few weeks ago. Thanks for considering, -d

Bug#846177: [Pkg-rust-maintainers] Bug#846177: A rustc-src package would be useful for racer completion

> I'm becoming a big fan of racer, so I'm all for this! I haven't > looked at the internals however - I presume racer only needs the > source for std (and core) not the compiler itself? Yes, I think you are correct: only libstd sources are needed, which are about 3 MiB. Two additional notes:

Bug#846177: A rustc-src package would be useful for racer completion

Source: rustc Severity: wishlist It would be nice to have a rustc-src package containing the source for Rust itself. The (widely-used) racer completion engine needs access to the source in order to work. There is precedent for this, for example Go provides a golang-src package. I don't think

Bug#843833: Could use shlibs bump after introducing symbol versioning

Package: liblua5.1-0 Version: 5.1.5-8.1 A binary built against 5.1.5-8 can run against previous versions of the library (e.g. jessie's), but it will print a warning: pandoc: /usr/lib/x86_64-linux-gnu/liblua5.1.so.0: no version information available (required by pandoc) It would be

Bug#841026: Pull: "userns: proc and sysfs mount fix"

Control: tags -1 - moreinfo > Are you sure you are seening the same bug? AFAICT, the > > mnt: Fix fs_fully_visible to verify the root directory is visible > > is as well included in the 3.16.7-ckt17-1 upload. Oh! That's a very good point indeed, thank you. I hadn't noticed. I tried

Bug#841026: Pull: "userns: proc and sysfs mount fix"

Package: linux-image-3.16.0-4-amd64 Version: 3.16.7-ckt17-1 The upload to jessie of linux 3.16.7-ckt17-1 included the following change: - mnt: Refactor the logic for mounting sysfs and proc in a user namespace [1] This broke mounting sysfs and procfs under a user namespace. There is a fix

Bug#816439: Grsec's RANDSTRUCT and Reproducible Builds

> While sill a long way Reproducible builds might pose a problem for a Grsec > kernel when CONFIG_GRKERNSEC_RANDSTRUCT is set to 'y' because this feature > randomizes kernel symbols and structures during compilation and is not meant > to be the same. For a publicly distributed kernel binary this

Bug#815952: parallel: should depend on procps for /bin/ps

Package: parallel Version: 20130922-1 parallel invokes /bin/ps, hence it should depend on procps. Thanks, -d

Bug#793809: please build packages for python3

> Please build packages for python3, using the upstream 1.1b1 release, maybe > uploading to experimental only. Please consider using at least 1.1rc4, to avoid running against this issue with Python 3.5: https://github.com/gevent/gevent/issues/653

Bug#803334: New release 2.0.0 available

, python, ruby + + * Use upstream’s build.sh for the build step. + + * Remove patches which no longer apply / are not needed: + +- 0001-build-with-libjs-coffeesciprt.patch +- 0002-Don-t-use-ld.gold-when-building-webkit.patch + + -- Dato Simó <d...@debian.org> Thu, 28 May 2015 20:36:42

Bug#802482: New upstream version available; help offered

Package: calendarserver Severity: wishlist There is a new version of calendarserver available. It would be nice to have it packaged for Debian. I might be able to help if you’d like. I see in the repository that you’ve imported upstream/7.0. You can let me know if there are any blockers so far.

Bug#801071: Should this package be removed?

retitle 801071 Please remove minirok from the archive reassign 801071 ftp.debian.org stop Hello— I agree with Moritz: let’s remove minirok from the archive. I’m maintainer and upstream. I don’t have intentions to work on it any further. Thanks, Moritz Muehlenhoff writes: >

Bug#761339: specify pycalendar version in Depends

Package: calendarserver Version: 5.2+dfsg-2 Severity: minor calendarserver’s dependency on python-pycalendar should be = 2.0~svn13177-1. This is only a very minor fix, but would be helpful if anybody backports calendarserver 5.2 to wheezy. -- To UNSUBSCRIBE, email to