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

[Dato Simó]

> 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

[Dato Simó]

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 sphinx -N -E -b html ...

Running Sphinx v1.8.5

Sphinx version error: This project needs at least Sphinx v3.5.0
and therefore cannot be built with this version.

make[1]: *** [debian/rules:40: override_dh_sphinxdoc] Error 2
```

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

[Dato Simó]

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 workflows

Toys is a configurable command line tool. Write commands in Ruby 
using a simple DSL, and Toys will provide the command line 
executable and take care of all the details such as argument 
parsing, online help, and error reporting.

Toys is designed for software developers, IT professionals, and 
other power users who want to write and organize scripts to 
automate their workflows. It can also be used as a replacement for 
Rake, providing a more natural command line interface for your 
project's build tasks.

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

[Dato Simó]

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 compatibility link such as:

  /usr/lib/rustlib/src/rust/src -> /usr/src/rustc-1.31.0/src

This way the source is still, as per policy, in /usr/share/src, 
but we'd be saved from having to configure every tool to use that 
path, and/or to maintain a local symlink, and keep it updated.

Thanks for considering,

-d

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

[Dato Simó]

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

[Dato Simó]

> 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 unstable 
from the ‘emacs’ source package, because it would have to migrate 
to testing; it's not possible to migrate a subset of binary 
packages.

Two options I can think of are:

  1. have a separate emacs-xwidgets _source_ package, confined to 
 unstable.

  2. ‘abuse’ the experimental suite, and re-upload there every 
 unstable version verbatim, with xwidgets support

 2.a: ... in a separate emacs-xwidgets package, OR
 2.b: ... in the main emacs package

(2.a) would need checking with ftpmaster, just to be sure they're 
okay; (2.b) is simpler but misleading (upgrading from experimental 
to a higher version in unstable will _lose_ you features). (1) is 
typically frowned upon.

Just to be clear, I can volunteer to make these uploads if needed. 
I'm rebuilding form myself anyway. 

Cheers,

-d

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

[Dato Simó]

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 it.

> I installed this package and golang-1.10-doc, and no 
> documentation for the standard library was provided.

Same here. While no HTML is provided, I guess godoc is extracting 
documentation from the source files at runtime.

Thanks,

-d

Bug#917132: Do not compress favicon.ico file

[Dato Simó]

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

[Dato Simó]

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 be nice being able to skip installing mailutils if 
downloading e-mail with Emacs is not needed.

Many thanks for considering,

-d

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

[Dato Simó]

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

[Dato Simó]

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 considering,

-d

Bug#906235: Library documentation not included

[Dato Simó]

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

[Dato Simó]

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

[Dato Simó]

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

[Dato Simó]

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 marked as beta.

Latest release of both flavors was on 2017-08-16 (14 days ago as
of this writing).

-d

Bug#862050: New upstream bugfix release 25.2 available

[Dato Simó]

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)

[Dato Simó]

Thanks for the prompt upload!

Much appreciated.

-d

Bug#851596: New stable release 0.9.18

[Dato Simó]

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

[Dato Simó]

> 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:

  1. the _root_ location of the source SHOULD be
 ‘$prefix/lib/rustlib/src’ (this has been standardized
 by the Rust community, see [rust-buildbot#102]).

 In other words, the following file should exist after
 installing the package:

 /usr/lib/rustlib/src/rust/src/libstd/io/mod.rs

 Racer has already been updated to search the source there,
 in the absence of RUST_SRC_PATH (see [racer#598]).

  2. If only libstd is included, perhaps the package should be
 named libstd-rust-src (for symmetry with libstd-rust-dev),
 instead of rust-src.

Thanks for considering,

d.


[rust-buildbot#102]
https://github.com/rust-lang/rust-buildbot/pull/102#issuecomment-222771857

[racer#598] https://github.com/phildawes/racer/pull/598

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

[Dato Simó]

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 that the racer dependency on the source code is
going away any time soon — though if it were, that would be a
reason not to introduce a source package.

Thanks for considering,

-d

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

[Dato Simó]

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 convenient to bump shlibs to avoid this.

-d

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

[Dato Simó]

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 3.16.7-ckt17-1: still get EPERM when trying to mount /proc on a
user namespace.

For reference, I'm seeing the bug when using vagga, a tool to manage
user namespaces.

The bug seems awfully similar to
https://github.com/tailhook/vagga/issues/12.

I'm going to leave a note in that bug pointing to here. I have no idea
what's going on, but the symptoms are the same.

Thanks!

-d

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

[Dato Simó]

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 at [2] that claims to solve the problem.

It would be great if this fix could be included in the next upload to
jessie.

Sadly, I haven't had time to run on my machine a kernel that includes
that fix. I do know, however, that the problem is still present in
3.16.36-1+deb8u1.

Thanks for considering,

-d

[1]: Original commit (I believe): https://patchwork.kernel.org/patch/6408681/
[2]: Fix: 
https://lists.linuxfoundation.org/pipermail/containers/2015-May/035874.html

Bug#816439: Grsec's RANDSTRUCT and Reproducible Builds

[Dato Simó]

> 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 feature does
> not provide any protection anyhow because these addresses are already known.
> This feature will need to be disabled for full compatibility with
> reproducible build systems.

Just FYI, the @grsecurity account tweeted the following today:

Contrary to: https://bugs.debian.org/816439, RANDSTRUCT is
actually compatible with reproducible builds, just need to
keep randomize_layout_seed.h.

https://twitter.com/grsecurity/status/704869584218685440

No idea how relevant this is for reproducible builds in Debian. Just
relaying it.

Ciao,
-d

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

[Dato Simó]

Package: parallel
Version: 20130922-1

parallel invokes /bin/ps, hence it should depend on procps.

Thanks,
-d

Bug#793809: please build packages for python3

[Dato Simó]

> 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

[Dato Simó]

Package: phantomjs  
Severity: wishlist

There’s a new upstream version available, 2.0.0.

I packaged it for a project at work, and I’m attaching the patch.

Unfortunately, this patch does not use the system Qt/QtWebKit—
though it does use all other system libraries, libjpeg,
libfreetype, etc.

Ciao,  
-d


diff --git a/phantomjs/debian/changelog b/phantomjs/debian/changelog
index 5b880f5..d275c4a 100644
--- a/phantomjs/debian/changelog
+++ b/phantomjs/debian/changelog
@@ -1,3 +1,30 @@
+phantomjs (2.0.0-0.1) unstable; urgency=low
+
+  * Update to version 2.0.0.
+
+  * Adjusted build dependencies:
+
++ remove:
+  - libqt4-dev (we use embedded Qt5)
+  - libjs-coffeescript (dropped upstream)
+
++ add dependencies needed for Qt5:
+  - libicu-dev
+  - libharfbuzz-dev
+  - libpcre3-dev
+
++ add dependencies needed for WebKit:
+  - flex, bison, gperf, 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 -0300
+
 phantomjs (1.9.0-1) unstable; urgency=low
 
   * Imported Upstream version 1.9.0 (Closes: #685404, #702381)
diff --git a/phantomjs/debian/control b/phantomjs/debian/control
index 63619e3..3379fd5 100644
--- a/phantomjs/debian/control
+++ b/phantomjs/debian/control
@@ -3,17 +3,21 @@ Section: web
 Priority: extra
 Maintainer: TANIGUCHI Takaki <tak...@debian.org>
 Build-Depends: debhelper (>= 7.0.50~),
-	libqt4-dev,
-	libjs-coffeescript
+	, bison
+	, flex
+	, gperf
 	, libfreetype6-dev
+	, libharfbuzz-dev
+	, libicu-dev
 	, libjpeg-dev
+	, libpcre3-dev
 	, libpng-dev
 	, libsqlite3-dev
 	, libssl-dev
 	, libz-dev
 	, libfontconfig1-dev
-	, libx11-dev
-	, libxext-dev
+	, python
+	, ruby
 Standards-Version: 3.9.3
 Homepage: http://www.phantomjs.org/
 Vcs-Git: git://git.debian.org/collab-maint/phantomjs.git
diff --git a/phantomjs/debian/patches/0001-build-with-libjs-coffeesciprt.patch b/phantomjs/debian/patches/0001-build-with-libjs-coffeesciprt.patch
deleted file mode 100644
index 851a6e3..000
--- a/phantomjs/debian/patches/0001-build-with-libjs-coffeesciprt.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-From: TANIGUCHI Takaki <tak...@asis.media-as.org>
-Date: Sat, 29 Oct 2011 18:26:43 +0900
-Subject: build with libjs-coffeesciprt
-

- python/pyphantomjs/csconverter.py |2 +-
- python/pyphantomjs/resources.qrc  |1 -
- src/csconverter.cpp   |2 +-
- src/phantomjs.qrc |1 -
- 4 files changed, 2 insertions(+), 4 deletions(-)
-
-Index: phantomjs/src/csconverter.cpp
-===
 phantomjs.orig/src/csconverter.cpp	2013-05-09 09:58:59.548611914 +0900
-+++ phantomjs/src/csconverter.cpp	2013-05-09 09:59:36.460792369 +0900
-@@ -49,7 +49,7 @@
- : QObject(QCoreApplication::instance())
- {
- m_webPage.mainFrame()->evaluateJavaScript(
--Utils::readResourceFileUtf8(":/coffee-script/extras/coffee-script.js"),
-+Utils::readResourceFileUtf8("/usr/share/javascript/coffee-script/coffee-script.js"),
- QString("phantomjs://coffee-script/extras/coffee-script.js")
- );
- m_webPage.mainFrame()->addToJavaScriptWindowObject("converter", this);
diff --git a/phantomjs/debian/patches/0002-Don-t-use-ld.gold-when-building-webkit.patch b/phantomjs/debian/patches/0002-Don-t-use-ld.gold-when-building-webkit.patch
deleted file mode 100644
index 26f7997..000
--- a/phantomjs/debian/patches/0002-Don-t-use-ld.gold-when-building-webkit.patch
+++ /dev/null
@@ -1,32 +0,0 @@
->From 03dd5a6ca3fca08fd35e37dfe93e7aca27728b00 Mon Sep 17 00:00:00 2001
-From: Eric Cooper <e...@cmu.edu>
-Date: Mon, 19 Nov 2012 15:16:58 -0500
-Subject: [PATCH] Don't use ld.gold when building webkit
-
-
-Signed-off-by: Eric Cooper <e...@cmu.edu>

- src/qt/src/3rdparty/webkit/Source/common.pri |7 ---
- 1 file changed, 7 deletions(-)
-
-diff --git a/src/qt/src/3rdparty/webkit/Source/common.pri b/src/qt/src/3rdparty/webkit/Source/common.pri
-index 0f62e14..093647a 100644
 a/src/qt/src/3rdparty/webkit/Source/common.pri
-+++ b/src/qt/src/3rdparty/webkit/Source/common.pri
-@@ -3,13 +3,6 @@
- contains(JAVASCRIPTCORE_JIT,yes): DEFINES+=ENABLE_JIT=1
- contains(JAVASCRIPTCORE_JIT,no): DEFINES+=ENABLE_JIT=0
- 
--linux-g++ {
--isEmpty($$(SBOX_DPKG_INST_ARCH)):exists(/usr/bin/ld.gold) {
--message(Using gold linker)
--QMAKE_LFLAGS+=-fuse-ld=gold
--}
--}
--
- # We use this flag on production branches
- # See https://bugs.webkit.org/show_bug.cgi?id=60824
- CONFIG += production
--- 
-1.7.10.4
-
diff --git a/phantomjs/debian/patches/series b/phantomjs/debian/patches/series
deleted file mode 100644
index b2f64d1..000
--- a/phantomjs/debian/patches/series
+++ /dev/n

Bug#802482: New upstream version available; help offered

[Dato Simó]

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.

Thanks,  
-d

Bug#801071: Should this package be removed?

[Dato Simó]

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:

> Package: minirok
> Severity: serious
>
> Should minirok be removed? It hasn't seen an upload
> since 2009, it's dead upstream (Debian maintainer is also
> upstream), popcon usage is marginal and it relies on
> obsolete gstreamer 0.10. Plus, there's plenty of alternatives
> in the archive.
>
> Please address the outstanding bugs or reassign this to
> ftp.debian.org for removal.
>
> Cheers,
> Moritz

Bug#761339: specify pycalendar version in Depends

[Dato Simó]

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 debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org