Bug#1067870: RM: keybinder -- RoQA; depends on gtk2, gtk3 replacement exists

[Esa Peuha]

Package: ftp.debian.org
Control: affects -1 + src:keybinder

It seems that all reverse (build-)dependencies have migrated to
keybinder-3.0 so this can be removed.

Bug#1064094: setuptools-scm-git-archive shouldn't be in trixie

[Esa Peuha]

Source: setuptools-scm-git-archive
Severity: serious

setuptools-scm-git-archive shouldn't be released as part of trixie.
It's broken with setuptools-scm 8 [1] and redundant starting with
setuptools-scm 7 [2], there is a removal request from unstable [3],
and apparently all the remaining source packages that still have
a build-dependency on it will remove it in future uploads.

[1] https://ci.debian.net/packages/s/setuptools-scm-git-archive
[2] https://github.com/Changaco/setuptools_scm_git_archive
[3] https://bugs.debian.org/1060027

Bug#1062608: urwid: B-D on deprecated python3-setuptools-scm-git-archive

[Esa Peuha]

Source: urwid
Version: 2.4.6-0.1
Control: block 1060027 by -1

Currently urwid build-depends on python3-setuptools-scm-git-archive
which blocks removal of setuptools-scm-git-archive (bug #1060027).
It should build-depend on python3-setuptools-scm instead.

Bug#1053623: RM: rust-nom-4 -- RoM; superseded by rust-nom

[Esa Peuha]

Control: tags -1 - moreinfo

rust-ansi-parser 0.8.0-2 no longer depends on rust-nom-4, so it can be
removed now.

Bug#1060454: RM: boost1.81 -- ROM; Superseded by boost1.83

[Esa Peuha]

Control: tags -1 - moreinfo

Both pbcopper and r-cran-openmx have switched to the default version of
boost, so there shouldn't be anything left to block boost1.81 removal.

Bug#967554: keybinder: depends on deprecated GTK 2

[Esa Peuha]

It seems that all reverse (build-)dependencies have switched to the
GTK3 alternative keybinder-3.0 so this one should be removed.

Bug#1061231: dak should understand versioned Provides

[Esa Peuha]

Package: ftp.debian.org

In daklib/rm.py virtual packages are parsed by the following code:

L143if provides is not None:
L144for virtual_pkg in provides.split(","):
L145virtual_pkg = virtual_pkg.strip()

This code makes no effort to handle the possibility that the provided
virtual package can specify a version. This has practical consequences;
for example, ghostscript provides ghostscript-x as a versioned virtual
package, but dak doesn't see that it can satisfy the remaining reverse
(build-)dependencies and therefore refuses to remove the cruft package
ghostscript-x (keeping it in the archive is particularly pointless
because it's no longer installable due to its unsatisfiable versioned
dependency on ghostscript).

Bug#967686: pcmanfm: depends on deprecated GTK 2

[Esa Peuha]

Control: reopen 967686

This isn't done yet. While the binary package no longer depends on
libgtk2.0-0, the source package still build-depends on libgtk2.0-dev.
That should be changed as well.

Bug#1000366: libpython3.10-stdlib: don't depend on transitional package mime-support

[Esa Peuha]

Package: libpython3.10-stdlib
Version: 3.10.0-4

This is the same bug as #981016 for 3.9: libpython3.10-stdlib should
depend directly on media-types instead of transitional mime-support
to avoid requiring mailcap and its dependency perl.

Bug#993287: "apt-get install" doesn't preserve autoinstall status of upgraded packages

[Esa Peuha]

On Mon, Aug 30, 2021 at 2:06 PM David Kalnischkies
 wrote:
>
> On Mon, Aug 30, 2021 at 11:27:47AM +0300, Esa Peuha wrote:
> > what has happened until recently. However, since apt 2.3.3 foo will be
> > marked as manually installed, which seems to be an unintended change.
>
> What makes you believe apt before 2.3.3 behaved differently?

Maybe apt didn't, but apt-get certainly did; I tested this by
downloading several versions of apt and libapt-pkg6.0 from
snapshot.debian.org and installing them on a live system. The
difference I see in apt-get is between 2.3.2 and 2.3.3.

> I tried with 2.3.2 and 1.3 (= the first release with CMake buildsystem)
> and both exhibit the behaviour you describe as an unintended change…
> (attached is a testcase akin to what Julian described were in both
> blocks the second apt-mark showmanual call fails as foo is now manual)

That test uses apt instead of apt-get, though. I never use apt myself,
so I didn't even think of finding out what it does.

Bug#993287: "apt-get install" doesn't preserve autoinstall status of upgraded packages

[Esa Peuha]

Package: apt
Version: 2.3.8

The man page for apt-get states that the command to upgrade a specific
package is "apt-get install". Therefore, if "apt-get install foo" does
upgrade package foo which has been marked as automatically installed,
I would expect foo's autoinstall status to be preserved, and this is
what has happened until recently. However, since apt 2.3.3 foo will be
marked as manually installed, which seems to be an unintended change.

Bug#939949: sleepyhead: B-D on cruft package

[Esa Peuha]

Source: sleepyhead
Version: 1.0.0-beta-2+dfsg-6
Severity: serious

Currently sleepyhead build-depends on libquazip5-headers, which is
no longer built from source as its contents have been merged into
libquazip5-dev, thus making sleepyhead unbuildable since these two
packages are not coinstallable. Please remove the build-dependency
on libquazip5-headers.

Bug#939745: python-nameparser: needs a source-only upload

[Esa Peuha]

Source: python-nameparser
Version: 1.0.4-1
Severity: serious

According to the Release Team, maintainer-uploaded binary packages
are no longer allowed to enter testing. Since it's not possible to
binNMU arch:all packages, a source-only upload is needed to get
python3-nameparser built on a buildd.

Bug#939663: freefem++: B-D on cruft packages

[Esa Peuha]

Source: freefem++
Version: 3.61.1+dfsg1-4
Severity: serious

Currently freefem++ build-depends on libpetsc-real3.10-dev and
libpetsc-complex3.10-dev which are no longer built from source.
Please update these build-dependencies.

Bug#935161: RM: chemfp -- RoQA; Python 2 only, B-D on cruft package, dead upstream

[Esa Peuha]

Package: ftp.debian.org
X-Debbugs-CC: che...@packages.debian.org

Please remove chemfp from unstable. It's Python 2 only, it build-depends
on python-rdkit which is no longer built by src:rdkit, and last upstream
activity was in 2013, so conversion to Python 3 is unlikely to happen.

Bug#935079: gnome-photos: unbuildable in testing due to missing B-D

[Esa Peuha]

Source: gnome-photos
Version: 3.30.1-2
Severity: serious

Currently gnome-photos build-depends on python-dogtail but it doesn't
exist in testing. This makes gnome-photos unbuildable in testing.
Please remove this build-depency.

Bug#935041: mh-e: unbuildable in testing due to missing B-D

[Esa Peuha]

Source: mh-e
Version: 8.5-2.1
Severity: serious

Currently mh-e build-depends on emacs25-nox | emacs25 | emacs24 but
none of these packages exist in testing. This makes mh-e unbuildable.
Please build-depend on emacs-nox | emacs-gtk instead.

Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25

[Esa Peuha]

Source: verilog-mode
Version: 20161124.fd230e6-2
Severity: serious

Currently verilog-mode build-depends on emacs25 which doesn't exist in
testing. This makes verilog-mode unbuildable. Please build-depend on
emacs-gtk instead.

Bug#934924: python-oslo.middleware: unbuildable in testing

[Esa Peuha]

Source: python-oslo.middleware
Version: 3.37.1-2

Currently python-oslo.middleware is unbuildable in testing because
three of its build-dependencies (python-hacking, python-oslotest,
python-stestr) have been removed. Please remove these and other
python 2 build-dependencies.

Bug#934825: python-yappi: migration blocked by binary upload

[Esa Peuha]

Source: python-yappi
Version: 1.0-1

python-yappi isn't migrating to testing due to a maintainer-uploaded
amd64 binary package. This blocks migration of python-oslo.service
which is currently unbuildable in testing. Please make a source-only
upload of python-yappi.

Bug#934750: python-pbr: autopkgtest regression

[Esa Peuha]

Source: python-pbr
Version: 5.1.3-3

As Debian CI logs [1] show, python-pbr 5.1.3-3 is consistently failing
its autopkgtest. This regression is blocking its migration to testing.
It looks like the test infrastructure is trying to run Python 2 tests,
even though Python 2 support was removed from the package.

[1] https://ci.debian.net/packages/p/python-pbr/testing/amd64

Bug#933623: transition: petsc

[Esa Peuha]

This transition isn't quite complete yet; src:freefem++ still
build-depends on libpetsc-{real,complex}3.10-dev.

Bug#934496: node-regexpu-core: unbuildable in testing due to missing B-D

[Esa Peuha]

Source: node-regexpu-core
Version: 4.5.4+ds+1
Severity: serious

Binary package node-unicode-12.0.0 is no longer built from source and
was removed from testing. As a result node-regexpu-core is unbuildable
in testing. Please build-depend on node-unicode-12.1.0 instead.

Bug#934382: cvxopt: FTBFS on non-amd64 architectures

[Esa Peuha]

Source: cvxopt
Version: 1.2.3+dfsg-1
Severity: serious

As shown by buildd logs [1], compiling src/C/umfpack.c fails on all
architectures except amd64 because umfpack.h is not found. This is
because line 61 of setup.py tests whether any files matching
/usr/lib/x86_64-linux-gnu/libsuitesparse* exist, which is false on
non-amd64 Debian buildds even when libsuitesparse-dev is installed.

[1] https://buildd.debian.org/status/package.php?p=cvxopt

Bug#934313: gertty: unbuildable in testing due to B-D on python-alembic

[Esa Peuha]

Source: gertty
Version: 1.5.0-3
Severity: serious

Binary package python-alembic is no longer built from source and has
been removed from testing. As a result, gertty is currently unbuildable
in testing. Please make gertty build-depend on python3-alembic instead.

Bug#934251: coinor-dylp: unbuildable in testing due to B-D on texlive-omega

[Esa Peuha]

Source: coinor-dylp
Version: 1.6.0-1.1
Severity: serious

src:texlive-base no longer builds binary package texlive-omega, which
has been removed from testing (and will be removed from unstable at
some point in the future, even if other packages still depend on it).
As a result, coinor-dylp is unbuildable in testing (and eventually is
going to be in unstable as well). Please fix this by changing the
build-dependency in coinor-dylp to texlive-formats-extra instead.

Bug#933061: piuparts.debian.org: missing bullseye

[Esa Peuha]

Package: piuparts.debian.org

On the left sidebar at https://piuparts.debian.org/ under "all tested
suites" there isn't a single line that mentions bullseye. Also, trying
to visit https://piuparts.debian.org/bullseye results in a 404 error.

Bug#932320: [Cross-toolchain-base-devs] Bug#932320: cross-toolchain-base-mipsen FTBFS in unstable

[Esa Peuha]

On Wed, Jul 17, 2019 at 8:40 PM Matthias Klose  wrote:
>
> please see
> https://lists.debian.org/debian-mips/2019/07/msg1.html

Well, if you don't want to fix c-t-b-mipsen, would you agree to have it
removed from testing? That should allow binutils and gcc to migrate.

Bug#932320: cross-toolchain-base-mipsen FTBFS in unstable

[Esa Peuha]

Source: cross-toolchain-base-mipsen
Version: 4
Severity: serious

Current version of cross-toolchain-base-mipsen FTBFS with binutils from
unstable (version 2.32.51.20190707-1). This is blocking binutils from
migrating from unstable to testing (which transitively blocks migration
of a bunch of other packages, including gcc-9).

It looks like the necessary fix to debian/rules was already applied to
cross-toolchain-base, but it should be in -mipsen as well.

Bug#883707: ace-freecell crashes on KDE desktops

[Esa Peuha]

I think I've found out what is causing this bug and why it only affects
freecell. When any of these games start up, the kde window manager sends
an expose event for one pixel at the top left corner, then an expose
event for the rest of the top row of pixels, then an expose event for
the remaining pixel rows. This unusual pattern makes no difference for
the other games, because their top row of pixels contains just empty
background. However freecell puts all of its initially empty card stacks
right at the top of its window, and to make these stacks visible to the
player, each of them has the "empty" picture on them. Therefore when
freecell gets the initial one-pixel expose event, that pixel happens to
be in the leftmost empty stack, so it has to draw the "empty" picture
there. In the process of doing so, function build_image in xwin.c calls
XGetImage to get an 8x8 pixel square from the top left corner of the
window as an ximage so that it can pass the depth, format and bitmap_pad
parameters to XCreateImage. Unfortunately at that point freecell hasn't
written anything (even the background color) to 255 of the 256 pixels
because they haven't been exposed yet, and (as far as I can tell) if
*no other program* has done so either, those pixels are uninitialized
and the call to XGetImage fails; at least that seems to be why freecell
starts to work after starting and quitting any other of these games.

I don't know whether the actual bug is in xwin.c or kde (or both), and
I don't think I want to dig deeper to find out. However, it should be
easy to work around the problem in freecell by moving the tops of the
empty stacks to the second row of pixels; here's a patch to do that.
Could you try it to make sure it works?
--- freecell.c~ 2015-06-08 16:15:20.771400783 +0300
+++ freecell.c  2018-02-27 19:47:05.272651935 +0200
@@ -71,10 +71,10 @@
 
   for (s=0; s<4; s++)
   {
-freecells[s] = stack_create(s*W, 0);
+freecells[s] = stack_create(s*W, 1);
 stack_set_empty_picture(freecells[s], empty);
 
-outcells[s] = stack_create(4*W+9*M+s*W, 0);
+outcells[s] = stack_create(4*W+9*M+s*W, 1);
 stack_set_empty_picture(outcells[s], empty);
   }
 

Bug#883707: ace-freecell crashes on KDE desktops

[Esa Peuha]

That's very odd. Presumably a program can only cause that error message
by calling XGetImage, and freecell (like every other of these games
except taipei) can only do so from line 819 of xwin.c in build_image.
However, the only non-constant arguments to XGetImage are display and
window, and if one of those variables has an invalid value, I would
expect an error long before reaching that point. Looking at the sources,
the only obvious difference between freecell and everything else is that
freecell defaults to a window that is 640 pixels wide and 480 pixels
high, and I can just about imagine that some piece of code might treat
a window with those exact dimensions specially. That should be easy to
test; if "ace-freecell -width 700 -height 500" works when it would fail
without those arguments, and if the other games fail if you start them
with "-width 640 -height 480" then it's pretty clear this is the cause.

Bug#873591: emacs doesn't un-maximize properly with openbox 3.6.1-5

[Esa Peuha]

Package: emacs25
Version: 25.2+1-5

I have an installation of Debian testing that uses openbox as its
window manager. Recently openbox was upgraded from version 3.6.1-4.1
to 3.6.1-5 which apparently broke emacs: if I open an emacs window and
maximize it, then un-maximizing the window doesn't restore it to its
previous size, but instead behaves as if I had manually resized it to
fill the entire screen. I'm filing this bug for emacs because I have
failed to find any other program that exhibits the same problem.

Bug#873057: ntp: ntpd not started at boot

[Esa Peuha]

On Thu, Aug 24, 2017 at 11:31 AM, Bernhard Schmidt  wrote:
> Can you show both
>
> systemctl status ntp.service

● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor
preset: enabled)
   Active: inactive (dead)
 Docs: man:ntpd(8)

Aug 25 14:39:00 debian-testing systemd[1]: ntp.service: Job
ntp.service/start finished, result=canceled
Aug 25 14:39:00 debian-testing systemd[1]: ntp.service: Installed new
job ntp.service/stop as 105
Aug 25 14:39:00 debian-testing systemd[1]: ntp.service: Job
ntp.service/stop finished, result=done

> systemctl status systemd-timesyncd.service

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service;
enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
   └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Fri 2017-08-25 14:39:00 EEST; 2min 47s ago
   └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
 Docs: man:systemd-timesyncd.service(8)

Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
Installed new job systemd-timesyncd.service/start as 102
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
ConditionFileIsExecutable=!/usr/sbin/VBoxService succeeded.
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded.
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded.
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
ConditionFileIsExecutable=!/usr/sbin/ntpd failed.
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
Starting requested but condition failed. Not starting unit.
Aug 25 14:39:00 debian-testing systemd[1]: systemd-timesyncd.service:
Job systemd-timesyncd.service/start finished, result=done

> and relevant systemd messages from boot (journalctl -b | grep systemd)?

Attached as a gzipped file.


journalctl-b-grep-systemd.gz
Description: GNU Zip compressed data

Bug#873057: ntp: ntpd not started at boot

[Esa Peuha]

Source: ntp
Version: 1:4.2.8p10+dfsg-5

I have an installation of Debian testing with ntp installed on it. With
ntp version 1:4.2.8p10+dfsg-3 and earlier, ntpd was started during boot,
but with 1:4.2.8p10+dfsg-4 and -5, ntpd isn't started (which BTW is far
from obvious; I became aware of the issue only after I noticed that the
machine's clock had drifted about a minute from the correct time). If I
copy /lib/systemd/system/ntp.service to /etc/systemd/system/ntp.service
and comment out the line "Conflicts=systemd-timesyncd.service" then ntpd
is started again, so I suggest that you remove that line. It shouldn't
be necessary for ntp to conflict with timesyncd anyway, because the file
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
checks if /usr/sbin/ntpd exists, and doesn't start timesyncd if it does.

Bug#833674: apt: Use ptsname_r if available

[Esa Peuha]

Source: apt

Commit 0a81c22 removed the test for ptsname_r from configure.ac but
there is a code block in apt-pkg/deb/dpkgpm.cc that is trying to use
ptsname_r if it exists. Although that code block is conditional inside
"#ifdef HAVE_PTS_NAME_R" while the configure test was trying to define
HAVE_PTSNAME_R so I don't think that has actually worked at all, but I
still think it would be better to put the configure test back and make
it work properly.

Bug#828000: emacs24: Missing toolbar icons

[Esa Peuha]

I can confirm that the proposed patch fixes the toolbar with LXDE.

Bug#832135: gcc-5: building liburcu on alpha crashes gcc

[Esa Peuha]

Package: gcc-5
Version: 5.4.0-6

According to this buildd log

https://buildd.debian.org/status/fetch.php?pkg=liburcu=alpha=0.9.2-3=1467933496

attempting to build liburcu 0.9.2-3 on alpha makes gcc 5.4.0-6 crash
with an internal compiler error (could not split insn). I don't have
access to an alpha system, so I can't confirm the crash myself, but
this should be simple to verify since the log has the preprocessed
source that gcc outputs when it crashes.

Bug#816319: Bugs missing from https://ftp-master.debian.org/removals.html

[Esa Peuha]

On Mon, Feb 29, 2016 at 11:26 PM, Mattia Rizzolo  wrote:
> actually, I think it's because those packages are already removed:

Well, at least one of them is (see below).

> * #812554: googlecl, already removed after #812553

Not really. Bug #812553 was a request to ftp-masters to remove
googlecl from unstable, but #812554 was a request to the release
team to remove it from the suites they manage. Since it no longer
was in those suites (it had already been removed from stable, and
I don't know if it ever was in oldstable) but was in oldoldstable
and stable-kfreebsd, the bug was reassigned to ftp-masters. Now
oldoldstable doesn't matter anymore, but stable-kfreebsd might
(if googlecl is still there, it should be removed).

> (and btw, I have a
>   feeling the title is not compliant, there shouldn't be the version
>   there)

I don't think that makes any difference; #782499 has even less
compliant title, but that didn't prevent it from being listed on
removals.html (although the autogenerated dak command line was
pretty weird).

> * #814109: php-html-table, already removed after #814105 (cloned once
>   too many)

No, the number of clones was correct, but the retitling wasn't:
clone 4 (bug #814108) was retitled twice while clone 5 (bug #814109)
wasn't retitled at all. This left package
php-structures-datagrid-datasource-array without a removal bug,
but it was removed anyway as part of #814107 since it depended
on php-structures-datagrid. So this one has nothing left to do.

> Now, I don't know whether removals.html should report wrongly opened
> bugs too, that's a thing for the ftp team.

I don't think it's fair to describe either of the bugs here as
"wrongly opened"; the first is a valid bug that might still need
to be acted on, and the second just suffers from a simple typo.

Bug#817939: RM: fw4spl -- RoQA; RC buggy, NPOASR, depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

fw4spl has had only three upload to Debian: the first two a few
days apart in March 2015, the third in July. It has never been in
a stable release, and not likely to be because it has two RC bugs
(#797475 and #797481) and at least one bug that is going to
become RC (#809935). fw4spl is also one of the packages blocking
the removal of insighttoolkit, so please remove it.

Bug#817938: RM: feel++ -- RoQA; abandoned, FTBFS, uninstallable, depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

The last upload of feel++ was in September 2014. It has two RC
bugs (#777848 and #811714) due to FTBFS, and now it is impossible
to even try to build it, since it build-depends on libopenmpi1.10
and libslepc3.4.2-dev which can't be installed at the same time.
Four out of the five binary packages built by src:feel++ are
uninstallable because they depend (directly or transitively) on
libgmsh2 which no longer exists in unstable. feel++ is also one
of the blockers to llvm-toolchain-3.5 removal. Please remove
feel++ from unstable.

Bug#817571: RM: ruby-hdfeos5-dbg -- RoQA; NBS, manual decrufting needed

[Esa Peuha]

Package: ftp.debian.org

Version 1.2-6 of src:ruby-hdfeos5 no longer builds a number of
packages that were built by 1.2-5; four of these (libhdfeos5-ruby,
libhdfeos5-ruby-doc, libhdfeos5-ruby1.9.1, and
libhdfeos5-ruby1.9.1-dbg) are arch:all while ruby-hdfeos5-dbg
is arch:any (and the only one I put in the subject line to keep
it short, although all of these should be removed). The
auto-decrufter can't handle this, so please decruft manually.

Bug#811158: No rdeps left

[Esa Peuha]

Control: tag -1 - moreinfo

ISTM there are no rdeps of mysql-5.5 left, so please remove it.

Bug#800414: src:minc should be removable now

[Esa Peuha]

Control: tag -1 - moreinfo

Unless I missed something, there is nothing blocking the removal
of src:minc now that caret is gone.

Bug#817148: RM: pinba-engine-mysql-5.5 -- RoQA; NBS, blocks mysql-5.5 removal

[Esa Peuha]

Package: ftp.debian.org

The current version of src:pinba-engine-mysql no longer builds
the binary package pinba-engine-mysql-5.5 which AFAICT is the
only blocker to mysql-5.5 removal, so please remove this
obsolete binary.

Bug#817047: nmu: cyphesis-cpp_0.6.0-3

[Esa Peuha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu

It seems that cyphesis-cpp has had problems building on several
architectures, with the result that it depends on various old
library packages on these arches. However the Reproducible Builds
project has managed [1] to build it repeatedly on both amd64 and
armhf since last December, so I think it is worth trying another
binNMU on all the problematic architectures.

[1] https://reproducible.debian.net/history/cyphesis-cpp.html

nmu cyphesis-cpp_0.6.0-3 . amd64 arm64 armel armhf i386 mips mips64el
mipsel . -m 'Rebuild against libmercator-0.3-4'

Bug#817043: RM: ruby-dev [all] -- RoQA; NBS, changed to arch:any

[Esa Peuha]

Package: ftp.debian.org

Version 1:2.3.0 changed ruby-dev from arch:all to arch:any.
Ideally, the automatic decrufter should remove the obsolete
arch:all ruby-dev 1:2.3~1, but instead it gets confused and
thinks that it would break every package that (build-)depends
on ruby-dev. So this one needs manual decrufting.

Bug#816918: RM: caret -- RoQA; unmaintained, RC buggy, depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

Last upload of caret was in 2012, it has one serious bug and
two important ones (both of which will almost certainly become
serious before the release of stretch), and it is the only
blocker to the removal of minc.

Bug#785770: RM: xserver-xorg-video-siliconmotion [arm64] -- RoP; FTBFS; out-of-date; uninstallable; quite possiblly never worked, little if any utility

[Esa Peuha]

On Wed, May 20 2015 Julien Christau wrote:
> Please don't do that quite yet.  I'm still undecided whether to keep the
> package in the archive at all.

Pinging you since you added the moreinfo tag to this bug; what
should be done with this package?

Bug#816823: nmu: freqtweak_0.7.2-4.1 rapidsvn_0.12.1dfsg-3

[Esa Peuha]

On Sat, Mar 5, 2016 at 4:34 PM, Emilio Pozuelo Monfort <po...@debian.org> wrote:
> On 05/03/16 15:08, Esa Peuha wrote:
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> Last year wxwidgets3.0 renamed its libraries from wx*3.0-0 to
>> wx*3.0-0v5 as part of the libstdc++6 transition, but there are
>> still packages using the old libraries. Out of these, freqtweak
>> and rapidsvn look like they could be fixed by a binNMU.
>>
>> nmu freqtweak_0.7.2-4.1 . ANY . -m "Rebuild against new wxwidgets3.0"
>> nmu rapidsvn_0.12.1dfsg-3 . ANY . -m "Rebuild against new wxwidgets3.0"
>
> Have you tried to rebuild them? Is #796450 fixed?

Sorry, I made a mistake by including rapidsvn in this request.
However freqtweak is rebuildable (in the Reproducible Builds
project [1] as well).

[1] https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/freqtweak.html

Bug#816823: nmu: freqtweak_0.7.2-4.1 rapidsvn_0.12.1dfsg-3

[Esa Peuha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu

Last year wxwidgets3.0 renamed its libraries from wx*3.0-0 to
wx*3.0-0v5 as part of the libstdc++6 transition, but there are
still packages using the old libraries. Out of these, freqtweak
and rapidsvn look like they could be fixed by a binNMU.

nmu freqtweak_0.7.2-4.1 . ANY . -m "Rebuild against new wxwidgets3.0"
nmu rapidsvn_0.12.1dfsg-3 . ANY . -m "Rebuild against new wxwidgets3.0"

Bug#816716: RM: ginkgocadx [!amd64 !i386] -- RoQA; dependency not available

[Esa Peuha]

Package: ftp.debian.org

The current version of ginkgocadx both build-depends and runtime
depends on insighttoolkit4 which is only available on amd64 and
i386. Please remove the obsolete binary packages on other
architectures.

Bug#816319: Bugs missing from https://ftp-master.debian.org/removals.html

[Esa Peuha]

Package: ftp.debian.org

There are currently two bugs missing from the page of Pending
Debian Package removals, and have been for some time: 812554
and 814109. Since there doesn't seem to be any other reason why
these are still open, I'm assuming it's because they are
missing from the page.

Bug#816178: RM: python-ldap-doc -- RoQA; obsolete, unmaintained, depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

In 2006 src:python-ldap-doc was split off from src:python-ldap and
moved to contrib because it build-depends on latex2html which at
the time was in non-free. However in 2009 latex2html changed its
license to GPLv2 and was moved to main, so there is no reason to
keep python-ldap-doc as a separate source package. It has also
been effectively abandoned, last update was in 2012, and it
depends on python-old-doctools which is going to be removed.

Bug#815926: RM: albatross -- RoQA; abandoned, dead upstream, depends on to-be-removed package, low popcon

[Esa Peuha]

Package: ftp.debian.org

The last maintainer upload of albatross was in 2008, and even the
last NMU was in 2013. Upstream looks dead too, last release was
in 2011. The source package build-depends on python-old-doctools
which is going to be removed. The popcon is very low, and there
are alternatives available (such as django). Please remove this
albatross around our necks. :-)

Bug#814612: RM: pyke -- RoQA; uninstallable, no rdeps, maintainer agrees

[Esa Peuha]

Package: ftp.debian.org

python-pyke depends on binary packages that are no longer built
from python-ply. There are no rdeps, just a reverse-recommends
which shouldn't block the removal. The maintainer of pyke also
wants it removed (see #799577 message #15).

Bug#814615: RM: openwalnut -- RoQA; uninstallable, unbuildable, unmaintained

[Esa Peuha]

Package: ftp.debian.org

openwalnut is uninstallable and unbuildable, and has been for at
least a year (see #778050).

Bug#814357: RM: fatrat -- RoQA; uninstallable, unbuildable, unmaintained

[Esa Peuha]

Package: ftp.debian.org

fatrat is uninstallable and unbuildable, and the last upload was
in 2012.

Bug#814256: RM: sshmenu -- RoQA; uninstallable, unmaintained, dead upstream

[Esa Peuha]

Package: ftp.debian.org

sshmenu has been uninstallable for one and a half years (#752821)
and already needed user tweaking to work for two years before that
(#677595). Upstream looks dead too, last release was six years ago.

Bug#814155: RM: vdkbuilder2 -- RoQA; uninstallable, unmaintained

[Esa Peuha]

Package: ftp.debian.org

Bug #743295 requested the removals of both vdkxdb2 and vdkbuilder2,
but only vdkxdb2 was removed, making vdkbuilder2 uninstallable.
Let's fix that omission.

Bug#814147: RM: ghdl -- RoQA; uninstallable, orphaned

[Esa Peuha]

Package: ftp.debian.org

ghdl is uninstallable (#695303) and orphaned (#696548), and
has been both for over three years. It is pointless to keep it in
unstable in its current state.

Bug#753800: tracker.debian.org: please give the details link some content

[Esa Peuha]

Here is a patch that hopefully fixes this issue. It adds two new
template tags, "octicon" which renders any octicon with alternate
text (which should appear as both mouseover text and text-mode-only
text), and "toggle_chevron" which gives a downward chevron to toggle
the display of details (this was so frequent special case that it
seemed worth its own tag). The only testing I have done is to make
sure that "manage.py test" didn't break.
diff --git a/distro_tracker/accounts/templates/accounts/subscriptions.html b/distro_tracker/accounts/templates/accounts/subscriptions.html
index 74f6168..ac52d67 100644
--- a/distro_tracker/accounts/templates/accounts/subscriptions.html
+++ b/distro_tracker/accounts/templates/accounts/subscriptions.html
@@ -1,5 +1,6 @@
 {% extends 'core/base.html' %}
 {% load staticfiles %}
+{% load distro_tracker_extras %}
 {% block title %}Subscriptions | {{ block.super }}{% endblock %}
 
 {% block extra-js %}
@@ -21,7 +22,7 @@
 
 
 Subscriptions for {{ email }}
-
+{% toggle_chevron %}
 {% if email_subscriptions.subscriptions %}
 {% csrf_token %}
 
@@ -61,7 +62,7 @@
 
 
 		
-		
+		{% toggle_chevron %}
 		
 		{% if subscription.package.get_absolute_url %}
 		{{ subscription.package }}
@@ -109,7 +110,7 @@
 
 
 		
-		
+		{% toggle_chevron %}
 		
 		{{ membership.team }}
 		
diff --git a/distro_tracker/core/panels.py b/distro_tracker/core/panels.py
index 7622a76..d72d0b2 100644
--- a/distro_tracker/core/panels.py
+++ b/distro_tracker/core/panels.py
@@ -25,6 +25,7 @@ from distro_tracker.core.models import PackageExtractedInfo
 from distro_tracker.core.models import MailingList
 from distro_tracker.core.models import News
 from distro_tracker.core.models import BinaryPackageBugStats
+from distro_tracker.core.templatetags.distro_tracker_extras import octicon
 from debian.debian_support import AptPkgVersion
 from collections import defaultdict
 
@@ -473,9 +474,8 @@ class VersionedLinks(BasePanel):
 
 class DscLinkProvider(VersionedLinks.LinkProvider):
 icons = [
-mark_safe(
-''),
+octicon('desktop-download',
+'.dsc, use dget on this link to retrieve source package'),
 ]
 
 def get_link_for_icon(self, package, index):
diff --git a/distro_tracker/core/templates/core/edit-team-membership.html b/distro_tracker/core/templates/core/edit-team-membership.html
index 6840046..77c4fe2 100644
--- a/distro_tracker/core/templates/core/edit-team-membership.html
+++ b/distro_tracker/core/templates/core/edit-team-membership.html
@@ -1,5 +1,6 @@
 {% extends 'core/base.html' %}
 {% load staticfiles %}
+{% load distro_tracker_extras %}
 
 {% block extra-js %}
 
@@ -21,8 +22,7 @@
 
 
 
-	
+	{% toggle-chevron %}
 {% if pkg.get_absolute_url %}
 {{ pkg }}
 {% else %}
diff --git a/distro_tracker/core/templates/core/octicon.html b/distro_tracker/core/templates/core/octicon.html
new file mode 100644
index 000..7af8464
--- /dev/null
+++ b/distro_tracker/core/templates/core/octicon.html
@@ -0,0 +1 @@
+{{ text }}
diff --git a/distro_tracker/core/templates/core/panels/action-needed.html b/distro_tracker/core/templates/core/panels/action-needed.html
index 427d648..9d4078c 100644
--- a/distro_tracker/core/templates/core/panels/action-needed.html
+++ b/distro_tracker/core/templates/core/panels/action-needed.html
@@ -1,5 +1,6 @@
 {% extends 'core/panels/panel.html' %}
 {% load 
+{% load distro_tracker_extras %}
 
 {% block panel-body %}
 
@@ -9,9 +10,8 @@
 	
-		
+		  class="chevron">
+		{% toggle-chevron %}
 	
 	{# The short description is allowed to contain some HTML markup #}
 	{{ item.short_description|safe }}
diff --git a/distro_tracker/core/templates/core/panels/news.html b/distro_tracker/core/templates/core/panels/news.html
index 9706bb7..fc696b3 100644
--- a/distro_tracker/core/templates/core/panels/news.html
+++ b/distro_tracker/core/templates/core/panels/news.html
@@ -1,12 +1,13 @@
 {% extends 'core/panels/panel.html' %}
+{% load distro_tracker_extras %}
 
 {% block panel-header %}
 
 
 	{{ panel.title }}
 	
-	
-	
+	
+	{% octicon 'rss' 'rss feed' %}
 	
 	
 
diff --git a/distro_tracker/core/templates/core/panels/versions.html b/distro_tracker/core/templates/core/panels/versions.html
index 595727d..e7e6416 100644
--- a/distro_tracker/core/templates/core/panels/versions.html
+++ b/distro_tracker/core/templates/core/panels/versions.html
@@ -1,4 +1,5 @@
 {% extends 'core/panels/panel.html' %}
+{% load distro_tracker_extras %}
 
 {% block panel-header %}
 
@@ -6,15 +7,15 @@
 {{ panel.title }}
 {% if panel.context.external_resources %}
 {% for external in panel.context.external_resources %}
-
-
+
+{% octicon 'link-external' external.description %}
 
 {% endfor %}
 {% endif %}
 {% with 

Bug#691374: remuco: stop building remuco-exaile

[Esa Peuha]

Control: reassign -1 src:remuco
Control: retitle -1 remuco: stop building remuco-exaile

Bug #813255 requests the removal of exaile. Since remuco-exaile
depends on exaile and has not worked for over three years, please
stop building remuco-exaile from source.

Bug#813926: RM: remuco-exaile -- RoQA; unusable, depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

According to bug #691374 remuco-exaile is incompatible with the
current exaile API (and has been for over three years) which makes
it unusable, and so it has very low popcon. Since it also blocks the
removals of exaile and moodbar, I think it would be best to remove
remuco-exaile without waiting for the maintainer to stop building
it from src:remuco.

Bug#813727: kfreebsd-10: update clang version

[Esa Peuha]

Source: kfreebsd-10
Control: block 812778 by -1

Currently freebsd-10 build-depends on clang-3.5 which is going to be
removed (see bug #812778), so please update to a newer version.

Bug#813501: RM: libcegui-mk2-dev [kfreebsd-amd64 kfreebsd-i386] -- RoQA; NBS, uninstallable

[Esa Peuha]

Package: ftp.debian.org

As a follow-up to bug #813317, libcegui-mk2-dev on kfreebsd-* is
also uninstallable and no longer built from source, so please remove
that as well.

Bug#813317: RM: libcegui-mk2-0.7.6 -- RoQA; NBS, uninstallable

[Esa Peuha]

Package: ftp.debian.org

After the recent removal of ogre-1.8 (bug #797423)
libcegui-mk2-0.7.6 is uninstallable, as well as anything that still
depends on it, so nothing can get more broken by removing
libcegui-mk2-0.7.6 and libcegui-mk2-0.7.6-dbg which are no longer
built from source.

Bug#813315: RM: kgamma/experimental -- RoQA; replaced by kgamma5

[Esa Peuha]

Package: ftp.debian.org

As a follow-up to #813196, please also remove kgamma from
experimental.

Bug#811007: information about build-deps on xchat

[Esa Peuha]

tag 811007 - moreinfo
thanks

Both cwirc and xchat-xsys have been removed, so now xchat can go too.

Bug#812744: RM: xchat-xsys -- RoQA; depends on to-be-removed package

[Esa Peuha]

Package: ftp.debian.org

Bug #811007 requests the removal of xchat since its upstream is dead
and the actively maintained fork hexchat is already in Debian. As
hexchat already has a plugin that does the same thing as xchat-xsys
for xchat, there is no reason to keep xchat-xsys.

Bug#785054: Please remove dependency on dpsyco

[Esa Peuha]

On Mon, May 11, 2015 Ola Lundqvist  wrote:

> I would like you to kindly remove the dependency on dpsyco-devel. I have
> attached a patch for that. The reason is that I have requested the removal
> of psyco source and this reverse dependency prevents that from happening.
> See bug #784869.

> I know it is my own fault that we have this dependency as I have added it
> myself sometime many years ago. I do not see the point of having it anymore.

> Please let me know if you want me to NMU the change.

Given how long this bug has been open and how trivial the patch is,
I think you can just go ahead and NMU harden-doc.

Bug#812341: RM: libconstantine-java/experimental -- RoQA; replaced by jnr-constants

[Esa Peuha]

Package: ftp.debian.org

As a follow-up to bug #811487, please also remove libconstantine-java
from experimental.

Bug#810848: ace-of-penguins: 4 doesn't call the four suits game

[Esa Peuha]

This is now fixed in CVS, so I suppose that's 1.5~rc2 then.

Bug#811274: nmu: mmpong smc

[Esa Peuha]

On Mon, Jan 18, 2016 at 4:21 PM, Jonathan Wiltshire  wrote:
> Is this going to happen often? I'm not excited by the idea of having to get
> involved every time the version number for cegui-mk2 gets incremented...

I'm afraid I don't know; the only reason I even noticed this is that
currently the removal of ogre-1.8 (#797423) is blocked by stale
cegui-mk2 binaries. After sending the binNMU request, I did notice
that there is an open transition bug for cegui-mk2 (#732763) that
is now a little over two years old, so if I had to guess, I'd say
there's no danger of cegui-mk2 getting too frequent updates...

Bug#810848: ace-of-penguins: 4 doesn't call the four suits game

[Esa Peuha]

On Mon, Jan 18, 2016 at 1:34 AM, Markus Koschany  wrote:
> The affected game is Penguin Spider. According to the help menu it
> should be possible to choose a four suits or two suits game by pressing
> the buttons 4 or 2. But pressing 4 or 2 in version 1.5~rc1 reshuffles
> the cards presenting a new one suite game. For me this looks like a bug
> or an intentional change but then the help menu is out-of-sync. What do
> you think?

This is definitely a bug. Pressing 1, 2 or 4 sets the variable
suit_mask and calls start_again() but currently suit_mask is only
used in init() which is only called once; IOW this is a case of
manual over-optimization. I will fix this in CVS as soon as I have
time to work on it (hopefully tomorrow).

Bug#811274: nmu: mmpong smc

[Esa Peuha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu

Recent update of the cegui-mk2 source package changed the name of the
binary package from libcegui-mk2-0.7.6 to libcegui-mk2-0.8.4 with the
result that the dependent packages need a binNMU. Apparently there
are only two of them in unstable, mmpong and smc. There doesn't seem
to be any problems with mmpong, but smc has been built on kfreebsd-*
on which the new cegui-mk2 source fails to build, so that might need
a dep-wait.

nmu mmpong_0.9.1-3 smc_1.9+git20121121-1.2 . ANY . -m 'Rebuild against
libcegui-mk2-0.8.4'
dw smc_1.9+git20121121-1.2 . kfreebsd-amd64 kfreebsd-i386 . -m
'libcegui-mk2-0.8.4'

Bug#811182: RM: apertium-en-es/experimental -- RoQA; newer version in unstable/testing

[Esa Peuha]

Package: ftp.debian.org

The version of apertium-en-es in experimental (0.8.0+svn~57502-1)
is older than the version in unstable and testing (0.8.0~r57502-1)
although the version strings unfortunately don't really reflect that.
I guess the actual contents of the packages are identical, since they
are based on the same svn revision, but I didn't check that.

Bug#793314: Let's just drop handlersocket

[Esa Peuha]

On Wed, 30 Dec 2015, Clint Byrum wrote:

> I orphaned it a long time ago, and nobody has stepped up to maintain, so
> I suggest just dropping it rather than chasing this RC.

The people who have the power to completely remove packages from
Debian are unlikely to notice this here, so please file a proper
removal request, i.e. file a bug for the pseudo-package
ftp.debian.org with subject "RM: handlersocket -- ROM; " and details of the reasons in the body. (I would do so
myself, but removal requests are expected to be filed by either
maintainer(s) of a package or the QA team, and I'm neither.)

Bug#808347: emacs24: FTBFS on ppc64el, ppc64: "Program segment above .bss"

[Esa Peuha]

On Fri, Dec 18, 2015 at 11:15 PM, Rob Browning  wrote:
> Actually, I think I may know the cause, but when I had time to poke at
> it last week(?), both of the porterboxes were down, and I haven't had a
> chance to get back to it yet.
>
> (I don't have a pointer handy, but iirc, it looked like there might an
>  upstream patch that we may be able to cherry-pick to fix the problem.)

You mean this upstream bug report

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20614

and the series of commits in upstream git master ending with

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3008c521740c5ad46a4eaf343b438b02c25e4de5

plus this single commit in the emacs-25 branch

http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25=c9fd597a4cffcae873b25381ee8cc755f0debe95

It certainly looks like these are worth trying.

Bug#808347: emacs24: FTBFS on ppc64el, ppc64: "Program segment above .bss"

[Esa Peuha]

Source: emacs24
Version: 24.5+1-5
Severity: serious

According to

https://buildd.debian.org/status/package.php?p=emacs24=sid

dumping emacs on ppc64el and ppc64 fails with

emacs: Program segment above .bss in
/«BUILDDIR»/emacs24-24.5+1/debian/build-x/src/temacs

which seems like it might be caused by some gcc/binutils issue
instead of an actual bug in emacs. Sorry I can't be more helpful;
I don't have access to any ppc machine, I only noticed this
because the failure on ppc64el is blocking the migration of
24.5+1-5 to testing (which is why I think this should have
severity level "serious").

Bug#808340: ace-of-penguins: please update to current upstream version

[Esa Peuha]

Package: ace-of-penguins
Version: 1.3-13

I have write access to the upstream Ace of Penguins CVS repository
at cvs.delorie.com/cvs/ace .  After the 1.4 release (which never
made it into Debian, although it's in Ubuntu) I have fixed a number
of bugs in that release, many of them related to the undo functions
of the card games. There are also other changes relative to the
Debian 1.3 package, notably 1) everything in debian/patches is now
included upstream, and 2) libxpm-dev is no longer needed to build
these games; that dependency was due to a leftover include
statement in one of the source files.

I have asked DJ Delorie to release the current CVS repository as
Ace of Penguins 1.5, but since that was six months ago and he
hasn't responded yet, I think it would be best to consider the
current CVS tree as 1.5~rc1 and release a new version of the
Debian package based on that.

Bug#808121: [Reproducible-builds] Bug#808121: diffoscope: HTML output is bloated

[Esa Peuha]

While we are at it, let's convert HTML character entity references
(which each use 6-8 characters and as many bytes in the HTML file)
to actual characters (which UTF-8 encodes as 2-3 bytes). Since all
diffoscope output files are peppered with abundant amounts of these
things, this could reduce the file sizes by a few percent at least.
I used Python string literals instead of the actual characters in
the Python file, because 1) the non-breaking and zero-width spaces
would be very hard to distinguish from ordinary space and missing
string content, respectively, and 2) it is impossible to be sure
that every piece of software that is ever going to be used to view
or edit the file would handle non-ASCII characters correctly.
--- presenters/html.py.orig 2015-12-16 19:42:25.0 +0200
+++ presenters/html.py  2015-12-17 15:10:53.654467937 +0200
@@ -290,9 +290,9 @@
 n = TABSIZE-(i%TABSIZE)
 if n == 0:
 n = TABSIZE
-t.write(''+''*(n-1))
+t.write('\xbb'+'\xa0'*(n-1))
 elif c == " " and ponct == 1:
-t.write('')
+t.write('\xb7')
 elif c == "\n" and ponct == 1:
 t.write('\')
 elif ord(c) < 32:
@@ -304,11 +304,11 @@
 i += 1
 
 if WORDBREAK.count(c) == 1:
-t.write('')
+t.write('\u200b')
 i = 0
 if i > LINESIZE:
 i = 0
-t.write("")
+t.write('\u200b')
 
 return t.getvalue()
 
@@ -353,7 +353,7 @@
 print_func(u'')
 else:
 s1 = ""
-print_func(u'')
+print_func(u'\xa0')
 
 if s2 is not None:
 print_func(u'%d ' % line2)
@@ -362,7 +362,7 @@
 print_func(u'')
 else:
 s2 = ""
-print_func(u'')
+print_func(u'\xa0')
 finally:
 print_func(u"\n", force=True)
 
@@ -522,7 +522,7 @@
 print_func(u"%s"
% escape(difference.source2))
 anchor = '/'.join(sources[1:])
-print_func(u" " % 
(anchor, anchor))
+print_func(u" \xb6" % 
(anchor, anchor))
 print_func(u"")
 if difference.comments:
 print_func(u"%s"

Bug#804140: Problem viewing list of usertagged bugs without specifying a tag

[Esa Peuha]

Package: bugs.debian.org

URLs such as

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=transition

that include a "tag" parameter work fine, but

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org

without that parameter will give a "500 Internal Server Error" after
a longish delay.

Bug#803482: ncurses: please make the build reproducible, take two

[Esa Peuha]

On Fri, Oct 30, 2015 at 10:44 PM, Sven Joachim  wrote:
> Certainly aclocal.m4 is _not_ a generated file in ncurses,

Not in the Debian package, but upstream must be generating it from
configure.in by running aclocal.

> Possible
> solutions are to run dh_strip_nondeterminism on the -dbg packages, or to
> just remove the static debug libraries (I don't think they actually
> work anyway, see #556378 for reasons).

I don't know if the static debug libraries work or not (wouldn't the
latter mean that #556378 isn't really fixed?), but I think
dh_strip_nondeterminism is probably the best option here.

Bug#803482: ncurses: please make the build reproducible, take two

[Esa Peuha]

Source: ncurses
Version: 6.0+20151024-1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While ncurses 6.0+20151017-1 fixed the earlier reproducibility bug
#801864, it also introduced a reproducibility regression; now all the
lib*_g.a files in the lib*-dbg packages are affected by the umask,
uid/gid and build time of the build environment. The reason for this
regression is upstream patch 20151010, specifically the update of
CF_AR_FLAGS in aclocal.m4 (which is propagated to configure) that
causes the static libraries to be generated with "ar -curvU". I don't
really know where this should be fixed (patching aclocal.m4 doesn't
seem right since it's a generated file) so I can't suggest a patch.

Bug#803061: calendarserver: please make the build reproducible

[Esa Peuha]

Source: calendarserver
Version: 5.2.2+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that calendarserver could not be built reproducibly.

The problem is that support/version.py expects that the output from
"svnversion -n" is in English, but it may be in any language depending
on the locale of the build environment. Here is a patch that sets
LC_ALL=C for the call to svnversion to fix it.

 [1]: https://wiki.debian.org/ReproducibleBuilds
--- support/version.py.orig	2014-10-21 07:31:12.0 +0300
+++ support/version.py	2015-10-26 15:42:28.191081976 +0200
@@ -40,7 +40,7 @@
 source_root = dirname(dirname(__file__))
 
 for branch in branches:
-svn_revision = subprocess.check_output(["svnversion", "-n", source_root, branch])
+svn_revision = subprocess.check_output(["LC_ALL=C", "svnversion", "-n", source_root, branch], shell=True)
 
 if "S" in svn_revision:
 continue

Bug#802481: apertium-en-ca: please make the build reproducible

[Esa Peuha]

Source: apertium-en-ca
Version: 0.9.3~r61232-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that apertium-en-ca (as well as other apertium-*-* packages) could not
be built reproducibly.

The problem is that these packages try to run localedef to compile
files for the en_US.UTF-8 locale in a nonstandard directory. This is
problematic because localedef needs the locales package to work, but
"Build-Depends: locales" isn't guaranteed to install locales if
locales-all is already installed (because locales-all contains
"Provides: locales" in its control file) and locales-all isn't good
enough for localedef. The solution is to simply build-depend on
locales-all instead of locales and use the locale files in the default
location; here is a patch to do that. (While the patch is against the
apertium-en-ca source package, essentially identical patches should be
applied to the other apertium-*-* packages as well.)

 [1]: https://wiki.debian.org/ReproducibleBuilds
diff -ur apertium-en-ca-0.9.3~r61232.orig/debian/control apertium-en-ca-0.9.3~r61232/debian/control
--- apertium-en-ca-0.9.3~r61232.orig/debian/control	2015-07-09 17:21:03.0 +0300
+++ apertium-en-ca-0.9.3~r61232/debian/control	2015-10-20 15:33:17.591980258 +0300
@@ -9,7 +9,7 @@
debhelper (>= 8.0),
dh-autoreconf,
gawk,
-   locales,
+   locales-all,
pkg-config (>= 0.21)
 Standards-Version: 3.9.6
 Homepage: http://apertium.org/
diff -ur apertium-en-ca-0.9.3~r61232.orig/debian/rules apertium-en-ca-0.9.3~r61232/debian/rules
--- apertium-en-ca-0.9.3~r61232.orig/debian/rules	2015-07-09 16:46:04.0 +0300
+++ apertium-en-ca-0.9.3~r61232/debian/rules	2015-10-20 15:33:01.701610251 +0300
@@ -20,8 +20,5 @@
 	dh $@ --with autoreconf
 
 override_dh_auto_build:
-	mkdir -p debian/tmp/locale/
-	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 && \
 	dh_auto_build

Bug#801864: ncurses: please make the build reproducible

[Esa Peuha]

Source: ncurses
Version: 6.0+20150810-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that ncurses could not be built reproducibly.

The problem is that the sort order of keys.list is affected by the
locale of the build environment. Here is a patch to fix that.

 [1]: https://wiki.debian.org/ReproducibleBuilds
--- ncurses/Makefile.in.orig	2015-08-06 02:15:41.0 +0300
+++ ncurses/Makefile.in	2015-08-06 02:15:41.0 +0300
@@ -225,7 +225,7 @@
 	./make_keys$(BUILD_EXEEXT) keys.list > $@
 
 keys.list :	$(tinfo)/MKkeys_list.sh
-	AWK=$(AWK) $(SHELL) $(tinfo)/MKkeys_list.sh $(TERMINFO_CAPS) | sort >$@
+	AWK=$(AWK) $(SHELL) $(tinfo)/MKkeys_list.sh $(TERMINFO_CAPS) | LC_ALL=C sort >$@
 
 make_keys$(BUILD_EXEEXT) : \
 		$(tinfo)/make_keys.c \

Bug#801212: unicode-data: please make the build reproducible

[Esa Peuha]

Source: unicode-data
Version: 8.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that unicode-data could not be built reproducibly.

The attached patch sets TZ=UTC before calling unzip, ensuring that
the modification time of the extracted files will not vary depending
on the timezone of the build enviromnent. Once this patch is applied,
unicode-data can be built reproducibly.

 [1]: https://wiki.debian.org/ReproducibleBuilds
--- debian/rules.orig   2015-06-20 15:14:56.0 +0300
+++ debian/rules2015-10-07 16:38:16.972507828 +0300
@@ -17,8 +17,8 @@
dh_testdir
mkdir -p $(SOURCE_DIR)
mkdir -p $(STAMP_DIR)
-   (cd $(SOURCE_DIR) && unzip ../UCD.zip )
-   (cd $(SOURCE_DIR) && unzip ../Unihan.zip )
+   (cd $(SOURCE_DIR) && TZ=UTC unzip ../UCD.zip )
+   (cd $(SOURCE_DIR) && TZ=UTC unzip ../Unihan.zip )
( find $(SOURCE_DIR) -name '*txt' | while read f; do \
tr -d \\r < $$f > tmpf  ; \
mv tmpf $$f ;   \

Bug#781326: please link to reproducible.d.n/$suite/$arch/$srcpkg

[Esa Peuha]

On Mon, Sep 28, 2015 at 10:21 AM, Paul Wise wrote:

> Hmm, the template links to .html:

No, it actually doesn't, it just looks like it does :-)  Notice how
the double quote is before the .html instead of after it.

Bug#793314: handlersocket: update to mysql-5.6

[Esa Peuha]

The current source repository is at
https://github.com/DeNA/HandlerSocket-Plugin-for-MySQL
and it seems to have fixes for mysql 5.6 (though I didn't try to compile it).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791716: libiconv-dev -- library to convert character encoding

[Esa Peuha]

Control: severity -1 wishlist
Control: retitle -1 RFP: libiconv-dev -- library to convert character encoding

Why do you think libiconv should be included in Debian? All of its
functionality is already provided by glibc (and AFAIK has been for
several Debian releases).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#469791: O: libmimedir -- A library to parse RFC 2425 Directory Information blocks

[Esa Peuha]

libmimedir was removed (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789203) so closing
this bug.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785079: RM: wxwidgets2.8 -- ROM; Unmaintained upstream; newer release packaged

[Esa Peuha]

block -1 by 751241 759044
thanks

Looks like codeblocks, gspiceui and sitplus have fixed versions
available, so that leaves just amule and tribler; marking their bugs
as blockers for this bug.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790618: FTBFS due to missing dependencies

[Esa Peuha]

Package: libdbd-oracle-perl
Version: 1.66-1
Severity: serious

The source package libdbd-oracle-perl build-depends on packages
oracle-instantclient12.1-basic and oracle-instantclient12.1-devel
which are not available, and therefore can no longer be built from
source.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#790358: please don't depend on clang-3.4

[Esa Peuha]

Package: kfreebsd-11
Control: block 783516 by -1

kfreebsd-11 currently depends on clang-3.4 which is going to be
removed (see bug #783516), so please update the dependency to a
newer version. Also, if possible, please do the same for kfreebsd-10.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786535: RM: openvas-libraries/experimental -- RoQA; unmaintained, outdated, uninstallable, ftbfs

[Esa Peuha]

I think greenbone-security-assistant should be removed for the same
reasons as openvas-*: it's based on openvas-scanner, already missing
build dependency libxslt-dev and therefore FTBFS, looks like buildd
could never build it on any architecture (binary package gsad on i386
was probably uploaded by the maintainer), gsad is missing runtime
dependency libmicrohttpd5, unmaintained since 2011, apparently unused
(it has no popcon entry at all).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787923: RM: apache2 -- NBS; ROM; Remove obsolete transitional packages

[Esa Peuha]

mod-auth-mysql has been removed, so there should be nothing blocking
removal of apache2.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785509: RM: appdata-tools -- ROM; deprecated, unused

[Esa Peuha]

The transitional appdata-tools from src:appstream-glib is in both
unstable and testing now, so it should be safe to go ahead with this.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785556: RM: php-math-biginteger -- ROM; Duplicate from php-seclib

[Esa Peuha]

I think that careful reading of
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
will be the best way to understand the situation here, but the most
important thing is that virtual packages can't have version numbers.
Therefore the line Provides: php-math-biginteger (= 1.0.2+phpseclib)
is broken, and currently appears to be ignored completely (but if the
syntax checking of the control file is ever made any stricter, it could
cause the package to be rejected). However, fixing it wouldn't help,
because php-horde-mapi depends on php-math-biginteger with version
constraints, so no virtual package can satisfy that dependency.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789793: broken PTS links on pending removals page

[Esa Peuha]

Package: ftp.debian.org

It seems that all links on http://ftp-master.debian.org/removals.html
that should point to packages' PTS pages are broken.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org