Bug#1069947: RM: wesnoth-1.16 -- ROM; superseded by wesnoth-1.18

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org, rho...@debian.org,
p...@pehjota.net
Control: affects -1 + src:wesnoth-1.16

Please remove wesnoth-1.16 now that wesnoth-1.18 has landed in sid. Thanks!

Regards,
Vincent

Bug#1057463: marked as pending in supertuxkart

[Vincent Cheng]

Hi Reiner,

On Sat, Jan 6, 2024 at 1:03 PM Reiner Herrmann  wrote:
>
> Control: tag -1 pending
>
> Hello,
>
> Bug #1057463 in supertuxkart reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/games-team/supertuxkart/-/commit/68a3bec7900d9921cb7f0428123db0eda945742a
>
> 
> Use system shaderc instead of embedded copy
>
> Closes: #1057463, #1031387
> 
>
> (this message was generated automatically)
> --
> Greetings
>
> https://bugs.debian.org/1057463

Just wanted to sanity check before uploading, is it ok for me to
upload what's currently in salsa to close out #1057463 (and #995771),
or are there other blockers / were you waiting on something else?
Either way, thanks for fixing these bugs in supertuxkart!

Regards,
Vincent

Bug#918360: [Python-apps-team] Bug#918360: pelican: pristine-tar: failed to generate tarball

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

On Sat, Jan 5, 2019 at 6:15 AM Geert Stappers  wrote:
>
> Package: pelican
> Version: 3.7.1
>
>
> stappers@paddy:~/src/salsa/pelican
> $ pristine-tar checkout pelican_3.7.1.orig.tar.gz
> xdelta: expected from file (/tmp/pristine-tar.f_NKRDwoMV/recreatetarball) of 
> length 2652160 bytes
> xdelta: expected from file (/tmp/pristine-tar.f_NKRDwoMV/recreatetarball) of 
> length 2652160 bytes
> xdelta: expected from file (/tmp/pristine-tar.ISkXh5ZYE0/recreatetarball) of 
> length 2652160 bytes
> xdelta: expected from file (/tmp/pristine-tar.aDYb0asTOz/recreatetarball) of 
> length 2652160 bytes
> xdelta: expected from file (/tmp/pristine-tar.aDYb0asTOz/recreatetarball) of 
> length 2652160 bytes
> pristine-tar: Failed to reproduce original tarball. Please file a bug report.
> pristine-tar: failed to generate tarball
> stappers@paddy:~/src/salsa/pelican
> $ pristine-tar checkout pelican_3.7.1+dfsg.orig.tar.gz
> xdelta: expected from file (/tmp/pristine-tar.EtCavfD9Nw/recreatetarball) of 
> length 256 bytes
> xdelta: expected from file (/tmp/pristine-tar.EtCavfD9Nw/recreatetarball) of 
> length 256 bytes
> xdelta: expected from file (/tmp/pristine-tar.cr56jbXfJe/recreatetarball) of 
> length 256 bytes
> xdelta: expected from file (/tmp/pristine-tar.Zhv2YE0Mq2/recreatetarball) of 
> length 256 bytes
> xdelta: expected from file (/tmp/pristine-tar.Zhv2YE0Mq2/recreatetarball) of 
> length 256 bytes
> pristine-tar: Failed to reproduce original tarball. Please file a bug report.
> pristine-tar: failed to generate tarball
> stappers@paddy:~/src/salsa/pelican

I can't repro this pristine-tar issue on my end:

$ pristine-tar checkout pelican_3.7.1.orig.tar.gz
xdelta: expected from file
(/tmp/pristine-tar.LM1U7cCS9t/recreatetarball) of length 2652160 bytes
xdelta: expected from file
(/tmp/pristine-tar.LM1U7cCS9t/recreatetarball) of length 2652160 bytes
xdelta: expected from file
(/tmp/pristine-tar.rN7_tY18Z4/recreatetarball) of length 2652160 bytes
xdelta: expected from file
(/tmp/pristine-tar.8GXjLM1JLS/recreatetarball) of length 2652160 bytes
pristine-tar: successfully generated pelican_3.7.1.orig.tar.gz
$ pristine-tar checkout pelican_3.7.1+dfsg.orig.tar.gz
xdelta: expected from file
(/tmp/pristine-tar.ydXe1jQGGx/recreatetarball) of length 256 bytes
xdelta: expected from file
(/tmp/pristine-tar.ydXe1jQGGx/recreatetarball) of length 256 bytes
xdelta: expected from file
(/tmp/pristine-tar.TUDALYUNdn/recreatetarball) of length 256 bytes
xdelta: expected from file
(/tmp/pristine-tar._2ygZjICZa/recreatetarball) of length 256 bytes
pristine-tar: successfully generated pelican_3.7.1+dfsg.orig.tar.gz

I'd be inclined to close this bug unless there's a way to reliably
reproduce this (in which case I'd honestly be inclined to just strip
out the pristine-tar deltas, but I guess that's another discussion to
be had).

Regards,
Vincent

Bug#1050361: RM: mangler -- RoQA; dead upstream; depends on gtk2

[Vincent Cheng]

Control: severity -1 important

On Wed, Aug 23, 2023 at 9:54 AM Bastian Germann  wrote:
>
> Source: mangler
> Severity: serious
> Version: 1.2.5-5
>
> mangler does not seem to be used a lot and is dead upstream. I doubt
> that Ventrilo is still a thing nowadays.
>
> I intend to file a RM bug.
> If you have any reasons to keep it in Debian please voice them here.
> To get people's attention, I am filing as a serious bug and will
> reassign to the FTP team when the package is autoremoved from testing.

AFAIK mangler is the only Ventrilo client packaged in Debian, so I'd
like to keep this package around until gtk2 removal is imminent (i.e.
#947713 is set to severity serious). I see no reason to remove this
package prematurely until that happens. I'll keep the package on life
support in the meantime.

Regards,
Vincent

Bug#1041966: conky-all: unkown variable '$journal'

[Vincent Cheng]

Control: tag -1 + confirmed help

On Tue, Jul 25, 2023 at 4:18 AM Marco Herrn  wrote:
>
> Package: conky-all
> Version: 1.18.3-1
> Severity: normal
>
> According to the package description this package provides support for
> systemd journal:
>
> “
>  This is a full conky with most compile options enabled:
>  .
>  Wayland, X11, XDamage, XDBE, Xft, MPD, MOC, math, hddtemp, portmon, RSS,
>  Weather, wireless, IBM, nvidia, eve-online, Imlib2,
>  apcupsd, I/O stats, argb, Lua and the cairo and imlib2 Lua bindings,
>  Audacious, PulseAudio, iCal, iconv, IRC, and systemd journal.
> ”
>
> Also the manpage lists “journal” as a known variable:
>
> “
>journal lines (type)
>   Displays  last N lines of the systemd journal.  The optional 
> type can be `user' or `system' which will show only the user or system 
> journal respectively.  By
>   default, all journal lines visible to the user are shown.  A 
> maximum of 200 lines can be displayed, or until the text buffer is filled.
> ”
>
> However, using this variable in the config file leads to the message
>
> “conky: unknown variable '$journal'”
>
> and conky itself displays the text
>
> “${journal}”

For anyone following along with this bug report, I could use some help
figuring out where the problem lies (a patch would be even better!).
Both conky-{std,all} are built with -DBUILD_JOURNAL=ON (can be
confirmed from the build log) and src:conky has a build-dep on
libsystemd-dev (which does have the necessary pkg-config files).
However cmake doesn't seem to actually be able to find libsystemd. I'm
not sure what's going on here.

Regards,
Vincent

Bug#1042567: pygame: Should Debian migrate to pygame-ce

[Vincent Cheng]

On Sun, Jul 30, 2023 at 5:27 AM Niels Thykier  wrote:
>
> Package: pygame
> Severity: normal
> X-Debbugs-Cc: ni...@thykier.net
>
> Hi
>
> It seems like the pygame community got split after an internal
> controversy:
> https://old.reddit.com/r/pygame/comments/1112q10/pygame_community_edition_announcement/
>
> The question now is whether Debian to track the fork or the original or
> both.
>
> A quick look at this upstream projects suggests that pygame-ce (the
> fork) seems to have run with the majority of the active contributors.
>
> Either way, there is a newer version of pygame / pygame-ce, that I would
> like to see in Debian. So please upgrade (either way). :)

My take on this split as the package maintainer (not involved in
either upstream community) is that I'm inclined to follow what other
distributions are doing, and it appears that other distros (Fedora,
Arch, Gentoo) are sticking with the original pygame; I haven't seen
anyone package the forked version. I intend on uploading pygame 2.5.0
soon.

Regards,
Vincent

Bug#1040357: conky-all: Stack trace of thread 4760

[Vincent Cheng]

On Tue, Jul 4, 2023 at 12:51 PM Tim McConnell  wrote:
>
> Package: conky-all
> Version: 1.18.3-1
> Severity: normal
>
> Stack trace of thread 4760:
>
>   #0  0x7f2a0c8a2ccc
> __pthread_kill_implementation (libc.so.6 + 0x8accc)
>   #10 0x565224f2323a n/a
> (conky + 0x8423a)
>   #1  0x7f2a0c853ef2
> __GI_raise (libc.so.6 + 0x3bef2)
>   #11 0x565224f24abf n/a
> (conky + 0x85abf)
>   #12 0x565224f24e35 n/a
> (conky + 0x85e35)
>   #13 0x565224f28275 n/a
> (conky + 0x89275)
>   #14 0x565224f06897 n/a
> (conky + 0x67897)
>   #15 0x565224f074af n/a
> (conky + 0x684af)
>   #16 0x565224ecf1bc n/a
> (conky + 0x301bc)
>   #17 0x565224ebdb74 main
> (conky + 0x1eb74)
>   #18 0x7f2a0c83f18a
> __libc_start_call_main (libc.so.6 + 0x2718a)
>   #19 0x7f2a0c83f245
> __libc_start_main_impl (libc.so.6 + 0x27245)
>   #20 0x565224ec4261 n/a
> (conky + 0x25261)
>   #2  0x7f2a0c83e472
> __GI_abort (libc.so.6 + 0x26472)
>   #3  0x565224f23497 n/a
> (conky + 0x84497)
>   #4  0x7f2a0d7a699b
> _XError (libX11.so.6 + 0x4699b)
>   #5  0x7f2a0d7a3607 n/a
> (libX11.so.6 + 0x43607)
>   #6  0x7f2a0d7a36a5 n/a
> (libX11.so.6 + 0x436a5)
>   #7  0x7f2a0d7a47fd
> _XReply (libX11.so.6 + 0x447fd)
>   #8  0x7f2a0d78a8eb
> _XGetWindowAttributes (libX11.so.6 + 0x2a8eb)
>   #9  0x7f2a0d78aa49
> XGetWindowAttributes (libX11.so.6 + 0x2aa49)
>   ELF object binary
> architecture: AMD x86-64
> I'm happy to give additional information just ask and give clear directions.

Please report this directly to upstream's bug tracker at
https://github.com/brndnmtthws/conky/issues, thanks!

Regards,
Vincent

Bug#1033175: FTBFS: setup.py install is deprecated

[Vincent Cheng]

Control: notfound -1 0.0.26-3
Control: close -1

On Sat, Mar 18, 2023 at 4:48 PM David W. Kennedy  wrote:
>
> Package: 0ad
> Version: 0.0.26-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: dav...@reasoned.us
>
> Hello,
>
> When I try to build 0ad version 0.0.26-3 in Debian unstable with
> python3.11 and python3-virtualenv, build fails.
>
> I think that the key error message is
> "/usr/lib/python3/dist-packages/setuptools/command/install.py:34:
> SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build
> and pip and other standards-based tools."
>
> The commands that I use to build the package:
>
> # apt-get update
> # apt-get build-dep 0ad
> $ apt-get source 0ad
> $ cd 0ad-0.0.26
> $ debuild

0ad/0.0.26-3 builds fine for me with an up-to-date pbuilder sid
chroot. I highly recommend building packages in a clean chroot
environment, using tools such as pbuilder or sbuild. Packages failing
to build from source in a dirty environment is not a RC bug and I
can't really help you debug why it's not working in your particular
environment.

Regards,
Vincent

Bug#1032259: conky: High CPU usage

[Vincent Cheng]

Control: severity -1 important

On Fri, Mar 3, 2023 at 5:48 AM Antoine Le Gonidec
 wrote:
>
> I think I can confirm that the high Xorg memory usage is due to this update, 
> I am now sitting at 3.30GB after a dozen hours.
>
> To make really sure of the cause, I am going to revert to the 1.17 build of 
> Conky and let it run for a dozen hours too.
>
> In the meantime I am bumping the bug severity again to prevent this memory 
> leak to reach Bookworm, once again feel free to revert that if you think that 
> is not such a big deal (I guess not everyone have X sessions running for 
> several days).

I'm downgrading severity because I can't repro it on my end, and I
don't think it qualifies as a RC bug unless it's more widespread. I'd
be happy to cherrypick a patch for this for bookworm once upstream
fixes the issue.

Regards,
Vincent

Bug#1032259: conky: High CPU usage

[Vincent Cheng]

On Thu, Mar 2, 2023 at 8:39 AM Antoine Le Gonidec
 wrote:
>
> I noticed that Xorg memory usage grows over time to unexpected levels. I 
> think it started at the same time than the high CPU usage so it might be 
> related, but I do not know how to make sure of that.

Please bisect if you have time and report this issue directly upstream
to their bug trakcer[1]. Thanks!

Regards,
Vincent

[1] https://github.com/brndnmtthws/conky/issues

Bug#1028308: mozjs78: FTBFS with python 3.11

[Vincent Cheng]

Source: mozjs78
Version: 78.15.0-5
Severity: serious
Tags: ftbfs

mozjs78 FTBFS since Python 3.11 became the default Python3 version in
sid. The relevant part of the build log is pasted below.

Incidentally, src:0ad happens to FTBFS for the same reason because it
embeds mozjs/spidermonkey [1]. You can see how we fixed this in 0ad
(unfortunately this involves cherry-picking an upstream commit to
upgrade virtualenv) [2].

```
checking for valloc in malloc.h... yes
checking for valloc in unistd.h... no
checking for _aligned_malloc in malloc.h... no
updating cache ./config.cache
creating ./config.data
Creating config.status
Traceback (most recent call last):
  File "/build/mozjs78-78.15.0/js/src/../../configure.py", line 181, in 
sys.exit(main(sys.argv))
 ^^
  File "/build/mozjs78-78.15.0/js/src/../../configure.py", line 57, in main
return config_status(config)
   ^
  File "/build/mozjs78-78.15.0/js/src/../../configure.py", line 142,
in config_status
partial_config.write_vars(sanitized_config)
  File 
"/build/mozjs78-78.15.0/python/mozbuild/mozbuild/backend/configenvironment.py",
line 361, in write_vars
self.substs._fill_group(substs)
  File 
"/build/mozjs78-78.15.0/python/mozbuild/mozbuild/backend/configenvironment.py",
line 257, in _fill_group
new_files.add(self._write_file(k, v))
  ^^
  File 
"/build/mozjs78-78.15.0/python/mozbuild/mozbuild/backend/configenvironment.py",
line 240, in _write_file
with FileAvoidWrite(filename) as fh:
  File "/build/mozjs78-78.15.0/python/mozbuild/mozbuild/util.py", line
338, in __exit__
self.close()
  File "/build/mozjs78-78.15.0/python/mozbuild/mozbuild/util.py", line
261, in close
existing = _open(self.name, self.mode)
   ^^^
  File "/build/mozjs78-78.15.0/python/mozbuild/mozbuild/util.py", line
59, in _open
return io.open(path, mode, encoding='utf-8', newline='\n')
   ^^^
ValueError: invalid mode: 'rU'
Configure failed with status 1
```

Regards,
Vincent

[1] https://bugs.debian.org/1028179
[2] 
https://salsa.debian.org/games-team/0ad/-/commit/7048ef33282782d9af46335c9d928dfa9d9f379d

Bug#1027895: conky-all: Conky window does not appear on second monitor

[Vincent Cheng]

Control: tag 1027895 + moreinfo

On Wed, Jan 4, 2023 at 3:21 AM Tecnosegugio  wrote:
>
> Package: conky-all
> Version: 1.17.0-1
> Severity: normal
> X-Debbugs-Cc: tecnosegu...@gmail.com
>
> Dear Maintainer,
>
> Conky-all 1.17.0-1 does not place the conky window on the correct monitor.
>
> I have two monitor, the second one is placed above the main monitor and I have
> configured GNOME to extend screen on two monitors.
> I'm used to place conky window on the second monitor, the one above the main
> monitor.
>
> Tried to edit xinerama_head value in .conkyrc file but nothing works.
>
> Tried to edit the alignment_* values but every changes seems related to the
> main monitor and not on the whoile logical screen.
>
> Downgrading to conky-all 1.12.2-2 restore correct behaviour

Does this behaviour change if you switch between X and wayland? Can
you try using the config settings `out_to_x` and `out_to_wayland` [1]
accordingly to see if it makes any difference? Wayland support was
recently introduced in conky so I'm wondering whether this might be a
factor.

As an interim hack, I think you can try playing around with negative
values for `gap_y` to make your conky output display on the desired
monitor.

Please also report this bug directly upstream at [2]. Thanks!

Regards,
Vincent

[1] https://conky.cc/config_settings
[2] https://github.com/brndnmtthws/conky/issues

Bug#1027856: RM: wesnoth-1.14/1:1.14.17-2

[Vincent Cheng]

retitle 1027856 RM: wesnoth-1.14 -- ROM; Package is superseded by wesnoth-1.16
reassign 1027856 ftp.debian.org
thanks

On Wed, Jan 4, 2023 at 12:11 AM Paul Gevers  wrote:
>
> Hi Vincent,
>
> On 04-01-2023 07:47, Vincent Cheng wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> >
> > src:wesnoth-1.14 has been superseded by wesnoth-1.16; please remove the 
> > former
> > from the archive. Thanks!
>
> If you want it removed from the archive (which sounds logical) than the
> bug should be reassigned to ftp.debian.org (and probably the title
> should be adapted to their format). Filing an RM bug against
> release.debian.org is what you should do if you want/need the package to
> remain in unstable for whatever reason but the package should be removed
> from testing (or stable). I think that's not what you meant, right?

Whoops, thanks for pointing me in the right direction!

Regards,
Vincent

Bug#1027856: RM: wesnoth-1.14/1:1.14.17-2

[Vincent Cheng]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

src:wesnoth-1.14 has been superseded by wesnoth-1.16; please remove the former
from the archive. Thanks!

Bug#967174: monster-masher: Unversioned Python removal in sid/bullseye

[Vincent Cheng]

+ debian-python

On Tue, Aug 4, 2020 at 2:32 AM Matthias Klose  wrote:
>
> Package: src:monster-masher
> Version: 1.8.1-8
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2unversioned
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> We will keep some Python2 package as discussed in
> https://lists.debian.org/debian-python/2020/07/msg00039.html
> but removing the unversioned python packages python-minimal, python,
> python-dev, python-dbg, python-doc.
>
> Your package either build-depends, depends on one of those packages.
> Please either convert these packages to Python3, or if that is not
> possible, replaces the dependencies on the unversioned Python
> packages with one of the python2 dependencies (python2, python2-dev,
> python2-dbg, python2-doc).
>
> Please check for dependencies, build dependencies AND autopkg tests.
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.

src:monster-masher has no build dependencies on python2, the only
binary package it builds (monster-masher) has no runtime dependencies
on python2, and this package has no autopkgtests. There's actually not
a single line of python in this package. Can I go ahead and close this
bug, or have I missed something?

Regards,
Vincent

Bug#967174: monster-masher: Unversioned Python removal in sid/bullseye

[Vincent Cheng]

On Tue, Aug 4, 2020 at 2:32 AM Matthias Klose  wrote:
>
> Package: src:monster-masher
> Version: 1.8.1-8
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2unversioned
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> We will keep some Python2 package as discussed in
> https://lists.debian.org/debian-python/2020/07/msg00039.html
> but removing the unversioned python packages python-minimal, python,
> python-dev, python-dbg, python-doc.
>
> Your package either build-depends, depends on one of those packages.
> Please either convert these packages to Python3, or if that is not
> possible, replaces the dependencies on the unversioned Python
> packages with one of the python2 dependencies (python2, python2-dev,
> python2-dbg, python2-doc).
>
> Please check for dependencies, build dependencies AND autopkg tests.
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.

src:monster-masher has no build dependencies on python2, the only
binary package it builds (monster-masher) has no runtime dependencies
on python2, and this package has no autopkgtests. There's actually not
a single line of python in this package. Can I go ahead and close this
bug, or have I missed something?

Regards,
Vincent

Bug#968540: O: mailnag -- extensible mail notification daemon

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the mailnag package.

Prospective maintainers should also consider adopting gnome-shell-mailnag.

The package description is:
 Mailnag is a daemon program that checks POP3 and IMAP servers for new mail.
 On mail arrival it performs various actions provided by plugins. Mailnag
 comes with a set of desktop-independent default plugins for visual/sound
 notifications, script execution etc. and can be extended with additional
 plugins easily

Bug#968541: O: gnome-shell-mailnag -- mail notification extension for GNOME Shell

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the gnome-shell-mailnag package.

Prospective maintainers should also consider adopting the mailnag package.

The package description is:
 This package provides GNOME Shell integration for Mailnag. It includes the
 following features:
 .
   - Notifies about new mails via the messaging tray (including a counter
 badge)
   - Shows an indicator in the top panel (including counter badge and popup
 menu)
   - Lock screen integration

Bug#968539: O: exaile

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the exaile package.

Exaile has been removed from sid (due to the current packaged version being
written in python2 and depending on multiple py2 libraries), but upstream has
since released 4.x which now supports python3. Packaging likely needs extensive
updates as a result.

Description: flexible, full-featured audio player
 Exaile is a media player which incorporates many of the cool things from
 Amarok (and other media players) like automatic fetching of album art,
 handling of large libraries, lyrics fetching, artist/album information via
 Wikipedia, last.fm support, and optional iPod support (assuming you have
 python-gpod installed).
 .
 In addition, Exaile also includes tabbed playlists (so you can have more
 than one playlist open at a time), blacklisting of tracks (so they don't
 get scanned into your library), downloading of guitar tablature from
 fretplay.com, and submitting played tracks on your iPod to last.fm.
 .
 Exaile aims to be similar to AmaroK, but uses Python and GTK+.

Bug#968537: O: tolua++ -- Tool to integrate C/C++ code with Lua - development files

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the tolua++ package.

Note that upstream is effectively dead and this package does not support newer
lua releases.

The package description is:
 tolua++5.1 is an extension of toLua, a tool to integrate C/C++ code with
 Lua. tolua++5.1 includes new features oriented to c++, such as class
 templates and is compiled with the newest lua 5.1.
 .
 Based on a "cleaned" header file, tolua++ automatically generates
 the binding code to access C/C++ features from Lua. Using Lua-5.1 API and
 metamethod facilities, the current version automatically maps C/C++
 constants, external variables, functions, namespace, classes, and methods
 to Lua. It also provides facilities to create Lua modules.
 tolua is a tool that greatly simplifies the integration of C/C++ code with
 Lua. Based on a cleaned header file, tolua automatically generates the
 binding code to access C/C++ features from Lua. Using Lua API and tag
 method facilities, tolua maps C/C++ constants, external variables,
 functions, classes, and methods to Lua.

Bug#968538: O: dbus-c++ -- C++ API for D-Bus (documentation)

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the dbus-c++ package.

The package description is:
 Dbus-c++ attempts to provide a C++ API for D-Bus. The library has a glib/gtk
 and an Ecore mainloop integration. It also offers an optional own main loop.

Bug#968536: O: cherrytree -- hierarchical note taking application

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the cherrytree package.

This package was removed from Debian due to python2 removals; upstream
currently has a WIP C++/gtkmm rewrite that can be packaged by a prospective
maintainer.

The package description is:
 CherryTree is a hierarchical note taking application, featuring rich text,
 syntax highlighting, images handling, hyperlinks, import/export with support
 for multiple formats, support for multiple languages, and more.

Bug#968535: O: logisim -- graphical tool for designing and simulating logic circuits

[Vincent Cheng]

Package: wnpp
Severity: normal

I intend to orphan the logisim package.

Upstream is no longer actively maintaining this package, but there are a number
of forks which are actively maintained that could be packaged instead.

The package description is:
 Logisim is an educational tool for designing and simulating digital logic
 circuits. With its simple toolbar interface and simulation of circuits as
 you build them, it is simple enough to facilitate learning the most basic
 concepts related to logic circuits. With the capacity to build larger circuits
 from smaller subcircuits, and to draw bundles of wires with a single mouse
 drag, Logisim can be used (and is used) to design and simulate entire CPUs
 for educational purposes.

Bug#968328: transition: gloox

[Vincent Cheng]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

I'd like to request a transition slot for src:gloox. This is a
relatively small transition, with only 2 source packages affected
(tested builds against newer gloox, currently in experimental, results
are as follows):

0ad (build ok, needs binNMU)
uwsgi (build ok, needs binNMU)

Ben file:

https://release.debian.org/transitions/html/auto-gloox.html is accurate.

Regards,
Vincent

Bug#949319: ITS: tolua++

[Vincent Cheng]

Hi Boyuan,

On Sun, Jan 19, 2020 at 11:39 AM Boyuan Yang  wrote:
>
> Source: tolua++
> Severity: important
> Version: 1.0.93-3
> X-Debbugs-CC: vch...@debian.org
>
> Hi Vincent,
>
> After looking into a package you maintain in Debian (tolua++,
> https://tracker.debian.org/pkg/tolua++), I found that this package received no
> update since 2012 and is not in good shape. As a result, I am filing an ITS
> (Intent to Salvage) request against your package according to section 5.12 in
> Debian Developers' Reference. [1]
>
> Please let me know if you are still willing to maintain this package.
> According to the criteria listed at [2], I will upload a Non-maintainer Upload
> (NMU) of tolua++ onto DELAYED/7 after 21 days (Feb. 09, 2020) to continue with
> the package salvaging. If it's necessary to pause the ITS process, please let
> me know immediately by replying this bug report.
>
> Thank you for your previous work on tolua++ and looking forward to your reply.

Sorry, I haven't been all that active in Debian recently. Please feel
free to take over and/or co-maintain the package if you'd like. Thanks
for taking care of this package!

Regards,
Vincent

Bug#917468: [Python-apps-team] Bug#917468: missing SVN repository data

[Vincent Cheng]

Hi Geert,

It should be part of the python-apps repo:

https://alioth-archive.debian.org/svn/python-apps.tar.xz

If you don't want to use that, at the very least import the last x versions
from snapshot.d.o, please don't just create a new repo from scratch.

Regards,
Vincent

On Fri, Dec 28, 2018, 5:03 AM Geert Stappers 
> At https://anonscm.debian.org/ is text saying
>   an archive of VCS repositories can be found on
> https://alioth-archive.debian.org/
>
> But under https://alioth-archive.debian.org/svn/ is _no_ pelican.tar.xz
>
>
> Unless a pelican SVN repo shows up, I will make git repo from scratch.
>
> ___
> Python-apps-team mailing list
> python-apps-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-apps-team

Bug#917468: [Python-apps-team] Bug#917468: pelican VCS field update

[Vincent Cheng]

Hi Geert,

If you could take the time to also properly migrate pelican's alioth SVN
history to salsa, that would be very much appreciated, thanks!

Regards,
Vincent

(On my phone, apologies for html and top posting)

On Thu, Dec 27, 2018, 4:21 PM Geert Stappers  Package: pelican
> Version: 3.7.1+dfsg-1
>
> Hi,
>
> debian/control of Pelican has VCS fields pointing
> to svn://anonscm.debian.org/python-apps/packages/pelican/trunk/
>
> My intention is to fix that with an NMU.
>
> This bugreport is documenting that.
>
>
> Groeten
> Geert Stappers
> DD
> --
> Leven en laten leven
>
> ___
> Python-apps-team mailing list
> python-apps-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-apps-team

Bug#908784: nethack: license incompatibility results in non-distributable binaries

[Vincent Cheng]

Hi James,

On Thu, Sep 13, 2018 at 2:51 PM James Cowgill  wrote:
>
> Source: nethack
> Version: 3.4.3-14
> Severity: serious
> X-Debbugs-CC: vch...@debian.org
>
> Hi,
>
> While reviewing the copyright file for the NetHack 3.6.1 upload, I
> noticed that the debian directory (and its patches) are marked as under
> the GPL-2.0. Unfortunately NetHack's special NGPL license is not
> compatible with the GPL (both are copyleft with some conflicting terms),
> so I have come to the conclusion that Debian's version of NetHack is not
> distributable in binary form at all.
>
> Thankfully I think this can be resolved fairly smoothly. If I look at
> the package history, I see that before 3.4.3-14 everything was licensed
> under the NGPL (except for the lisp patches). In this version, the
> copyright file was changed to relicense(?!) the debian/ directory under
> the GPL. Vincent and I are the only people who have claimed copyright
> since that point, and I am fine with licensing my stuff under the NGPL,
> so Vincent is the only person who needs asking.
>
> Vincent, can all your changes to the nethack package be licensed under
> the NGPL instead of the GPL-2.0?

Yes, I'm fine with licensing my changes to nethack under the NGPL as well.

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

On Fri, Aug 24, 2018 at 10:35 PM Theodore Y. Ts'o  wrote:
>
> I've submitted version 1.11.0-1 of f2fs-tools; it's currently in the
> NEW queue.
>
> The git tree for f2fs-tools is in Salsa:
>
> https://salsa.debian.org/debian/f2fs-tools
>
> The branches in the git tree are laid out to be DEP-14 compliant.  The
> master branch contains the debian packaging, and there is a gbp.conf
> file in the debian directory.  The f2fs-tools_1.11.0.orig.tar.gz was
> generated using:
>
> git archive --format tar --prefix f2fs-tools-1.11.0/ v1.11.0 | \
> gzip -9n > f2fs-tools_1.11.0.orig.tar.gz
>
> and is stored using pristine-tar in the pristine-tar branch.
>
> The 1.11.0-1 f2fs-tools packages were build using git-buildpackage,
> using the command "gbp buildpackage".  I'm using sbuild as my builder
> so I have in my ~/.gbp.conf:
>
> [buildpackage]
> builder = sbuild -A -s -v -d unstable
> export-dir = /tmp/gbp
> purge = False
>
> [tag]
> sign-tags = True
>
> And I have in my ~/.sbuildrc:
>
> $build_arch_all = 1;
> $distribution = 'unstable';
> $source_only_changes = 1;
>
> I fixed quite a few packaging issues while I was at it:
>
> f2fs-tools (1.11.0-1) unstable; urgency=medium
>
>   * New upstream release.   (Closes: #904286)
>  - add sg_write_buffer for UFS firmware update in Android
>  - wanted_sector_size to specify sector size explicitly
>  - support fsverity feature bit
>  - support lost+found feature
>   * Install the library link files in /usr/lib where they belong
>   * Replace the libf2fs0 package with libf2fs5 and libf2fs-format4
>   * Fixed missing libblkid dependency in the shared library
>   * Updated Standards compliance to 4.2.0
>   * Added Theodore Ts'o as an uploader for the package
>
>  -- Theodore Y. Ts'o   Fri, 24 Aug 2018 03:32:49 -0400

Thank you again for taking the time to give f2fs-tools some much needed TLC!

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

On Tue, Aug 21, 2018 at 6:32 PM, Vincent Cheng  wrote:
> On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o  wrote:
>> On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote:
>>>
>>> I can't find a reference right now, but I seem to recall that one of
>>> the Alioth admins pointed out that mailing lists specifically for
>>> package/bug tracking purposes (i.e. not used for discussion) shouldn't
>>> be migrated to lists.d.o. I don't know what other alternatives there
>>> are, however. I haven't really kept up with the Alioth
>>> migration/deprecation as you can probably tell. :)
>>
>> I thought there a difference between package-specific mailing lists
>> and groups that maintain a large number of packages (e.g., python, X,
>> etc.)  But I could be wrong.  I thought the lists.alioth.debian.org
>> was only guaranteed to be around for a year, but we do have time to
>> figure out what to do.
>
> It's certainly worth a try to see if the lists.d.o admins would allow
> the creation of a filesystems-devel list. Do we need someone to
> volunteer to be list admin for the new list? I did so when I requested
> for the old alioth list to be migrated to alioth-lists.d.n, but that
> was mostly to prevent RC bugs from kicking f2fs-tools out of testing,
> and not because I particularly enjoy being a list admin.

It looks like there's no need to nominate a specific person as list
admin, so I went ahead and filed #906898 to request that
debian-filesystems@l.d.o be created. If that falls through, maybe we
could piggyback on debian-kernel or some other list?

Regards,
Vincent

Bug#906898: lists.debian.org: Request for new mailing list: debian-filesystems

[Vincent Cheng]

Package: lists.debian.org
Severity: wishlist

Hi,

Since alioth-lists.debian.net is only a temporary service and is due
to be removed at some point in the future, I would like to request the
migration of filesystems-de...@lists.alioth.debian.org to
lists.debian.org.

Name: debian-filesyst...@lists.debian.org
Rationale: This new list would be a permanent replacement for the
temporary filesystems-devel list, and would serve as a central place
for discussing all filesystem/filesystem tools related issues in
Debian.
Short description: Filesystem tools packages and maintenance
Long description: Coordination of the maintenance of filesystem tools
packages in Debian.
Category: Developers
Subscription Policy: open
Post Policy: open
Web Archive: yes

Thanks!

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

On Tue, Aug 21, 2018 at 1:36 PM, Theodore Y. Ts'o  wrote:
> On Tue, Aug 21, 2018 at 01:01:10PM -0700, Vincent Cheng wrote:
>>
>> I can't find a reference right now, but I seem to recall that one of
>> the Alioth admins pointed out that mailing lists specifically for
>> package/bug tracking purposes (i.e. not used for discussion) shouldn't
>> be migrated to lists.d.o. I don't know what other alternatives there
>> are, however. I haven't really kept up with the Alioth
>> migration/deprecation as you can probably tell. :)
>
> I thought there a difference between package-specific mailing lists
> and groups that maintain a large number of packages (e.g., python, X,
> etc.)  But I could be wrong.  I thought the lists.alioth.debian.org
> was only guaranteed to be around for a year, but we do have time to
> figure out what to do.

It's certainly worth a try to see if the lists.d.o admins would allow
the creation of a filesystems-devel list. Do we need someone to
volunteer to be list admin for the new list? I did so when I requested
for the old alioth list to be migrated to alioth-lists.d.n, but that
was mostly to prevent RC bugs from kicking f2fs-tools out of testing,
and not because I particularly enjoy being a list admin.

>> Well, the shared library being split into a separate package was
>> intentional (#793863), but having never updated the package name is
>> not (I must have overlooked this somehow...). I wonder how I never got
>> any bug reports about this, because in theory that should mean that
>> android-libf2fs-utils (src:android-platform-system-extras) is flat out
>> broken (I never initiated any transitions or binNMU requests for
>> android-platform-system-extras after f2fs-tools updates).
>
> I think the right thing to do is to create separate packages for
> libf2fs and libf2fs_format.  (And the separate -dev packages, of
> course).  They have different so version numbers, and so there is no
> guarantee they will be both incremented in a particular release.  I'll
> work on that as part of the f2fs-tools 1.11 release.

I initially used Policy 8.1 as an excuse to lump them both into the
same binary package, but you're right, there is no guarantee that
soversion will change for both at the same time. Thanks!

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

On Fri, Aug 17, 2018 at 1:09 PM, Theodore Y. Ts'o  wrote:
> OK, I've created a new project in Salsa for f2fs-tools:
>
> https://salsa.debian.org/debian/f2fs-tools
>
> and I've uploaded git repo with a work-in-progress for a f2fs-tools
> v1.11.0 packaging.
>
> A couple of things which I've noted:
>
> 1)  The maintainers is listed as:
>
> filesystems-de...@lists.alioth.debian.org
>
> I wonder if it's worth it to migrate the mailing list over to
> lists.debian.org, and leave a forwarding pointer behind at the
> lists.alioth.debian.org address?  It will take a while to update all
> of the various file system utility packages to use a non-Alioth
> address, but I wonder if we should get started.  Not high priority, so
> we don't have to do this on this particular upload.

I can't find a reference right now, but I seem to recall that one of
the Alioth admins pointed out that mailing lists specifically for
package/bug tracking purposes (i.e. not used for discussion) shouldn't
be migrated to lists.d.o. I don't know what other alternatives there
are, however. I haven't really kept up with the Alioth
migration/deprecation as you can probably tell. :)

> 2)  In f2fs-tools 1.10.0-1, there is the shared libary package
> libf2fs0, which contains the shared libaries:
>
> libf2fs.so.4.0.0
> libf2fs_format.so.3.0.0
>
> In f2fs-tools 1.11.0 upstream, these have been bumped to:
>
> libf2fs.so.5.0.0
> libf2fs_format.so.4.0.0
>
> I very much doubt any other packages are actually depending on
> libf2fs0, but it seems wrong that we're using libf2fs0, as opposed to
> say, libf2fs4 and now libf2fs5.
>
> Was this intentional, or just one of those things that had never been
> noticed/fixed earlier?

Well, the shared library being split into a separate package was
intentional (#793863), but having never updated the package name is
not (I must have overlooked this somehow...). I wonder how I never got
any bug reports about this, because in theory that should mean that
android-libf2fs-utils (src:android-platform-system-extras) is flat out
broken (I never initiated any transitions or binNMU requests for
android-platform-system-extras after f2fs-tools updates).

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

On Sun, Aug 12, 2018 at 9:31 AM, Theodore Y. Ts'o  wrote:
> On Sun, Aug 12, 2018 at 02:19:29AM -0700, Vincent Cheng wrote:
>>
>> Sorry, I haven't had time lately to properly care for my packages.
>> Please go ahead with the NMU (bonus points if you have time to move
>> everything to salsa, extra bonus points if you're willing to
>> co-maintain the package too). Thanks!
>
> Was there a previous git repo for f2fs-tools on Alioth?  I didn't base
> my last upload of f2fs to stretch-backports (just started with the
> tree from "apt-get source f2fs-tools"), but if you want me to move it
> to Salsa, it would probably be a good idea to preserve the git repo
> (if any) you were of the Debian packaging.  Unfortunately I can't seem
> to find where the Alioth backups of the repos that were stored there
> can be found, and while I can try to ask for them, if you have a local
> git repo that you can push up to github or gitlab, that would be
> great.

There used to be a svn collab-maint repo on Alioth for f2fs-tools, but
unfortunately I didn't get a chance to migrate that to git before
Alioth was taken down. The f2fs-tools packaging isn't complex and the
svn history isn't particularly interesting, so it's probably not
worthwhile to grab the collab-maint svn dump and to try converting
that to git. Feel free to just start off the repo from scratch if
you'd like (if I had time I'd probably start off by importing the last
dozen or so snapshots with gbp, but I'm not picky about how the repo
is structured), or just skip it altogether.

> Otherwise I can just start a new git repo --- I already have
> f2fs-tools v1.11.0 already packaged up for {kvm,gce,android}-xfstests,
> and it was a desire to allow others to reproduce the VM image
> completely from sources and debian snapshots w/o having to manually
> compile f2fs-tools which is why I've been interested in keeping
> f2fs-tools updated in stable backports.
>
> So as far as co-maintenance, I'm happy to help, although I don't
> actually do much with f2fs myself (other as part of the kernel file
> systems regression testing).

Thanks! It's entirely up to you of course. I've just been asking the
same question to anyone at all who's shown interest in my packages so
I don't feel nearly as guilty about neglecting them as I otherwise
would. :)

Regards,
Vincent

Bug#904286: f2fs-tools: Please package f2fs-tools v1.11.0

[Vincent Cheng]

Hi Ted,

On Sat, Aug 11, 2018 at 7:42 AM, Theodore Y. Ts'o  wrote:
> On Sun, Jul 22, 2018 at 01:49:17PM -0400, Theodore Y. Ts'o wrote:
>>
>> Please consider packaginging f2fs-tools 1.11.0 from upstream.  This
>> release includes:
>>
>>   - add sg_write_buffer for UFS firmware update in Android
>>   - wanted_sector_size to specify sector size explicity
>>   - support fsverity feature bit
>>   - support lost+found feature
>>   - some critical bug fixes
>
> Hi Vincent,
>
> Do you think you will have time to update f2fs-tools to 1.11?  If not,
> would you be OK if I were to submit an NMU to update f2fs-tools?

Sorry, I haven't had time lately to properly care for my packages.
Please go ahead with the NMU (bonus points if you have time to move
everything to salsa, extra bonus points if you're willing to
co-maintain the package too). Thanks!

Vincent

Bug#901992: RM: wesnoth-1.13 -- ROM; made obsolete by wesnoth-1.14

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

src:wesnoth-1.13 has been made obsolete by wesnoth-1.14; please remove
src:wesnoth-1.13.

Bug#875738: [Python-apps-team] Bug#875738: cherrytree: The package has a new version available 0.38.2

[Vincent Cheng]

Hi Johann,

On Thu, May 31, 2018 at 6:58 AM, Johann Glaser  wrote:
> Hi!
>
> Please package the newest available version 0.38.4 (since 2017-12-02,
> i.e., half a year ago).
>
>   https://www.giuspen.com/cherrytree/#downl

Even if the latest cherrytree version were packaged, it would be
uninstallable in sid due to #822586 [1].

Regards,
Vincent

[1] https://bugs.debian.org/822586

Bug#900334: transition: gloox

[Vincent Cheng]

Hi Emilio,

On Wed, May 30, 2018 at 2:41 PM, Emilio Pozuelo Monfort
 wrote:
> Control: tags -1 confirmed
>
> On 29/05/18 11:00, Emilio Pozuelo Monfort wrote:
>> On 29/05/18 10:49, Vincent Cheng wrote:
>>> Package: release.debian.org
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> Severity: normal
>>>
>>> Hi,
>>>
>>> I'd like to request a transition slot for src:gloox. This is a
>>> relatively small transition, with only 2 source packages affected
>>> (tested builds against newer gloox, currently in experimental, results
>>> are as follows):
>>>
>>> 0ad (build ok, needs binNMU)
>>> uwsgi (build ok, needs binNMU)
>>
>> Let's wait for the curl transition to finish.
>
> curl has migrated to testing today. Go ahead.

I've uploaded gloox to sid and have confirmed that it's built on all
release archs. Please go ahead and schedule binNMUs, thanks!

Regards,
Vincent

Bug#900334: transition: gloox

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hi,

I'd like to request a transition slot for src:gloox. This is a
relatively small transition, with only 2 source packages affected
(tested builds against newer gloox, currently in experimental, results
are as follows):

0ad (build ok, needs binNMU)
uwsgi (build ok, needs binNMU)

Ben file:

(https://release.debian.org/transitions/html/auto-gloox.html is accurate)

Regards,
Vincent

Bug#900001: Conky crashes eventually on linux setups where net interfaces change often

[Vincent Cheng]

Hi Michael,

On Thu, May 24, 2018 at 7:21 AM, Michael Stummvoll  wrote:
> Package: conky
> Version: 1.10.8-1
> tags: patch
>
> Dear Maintainers,
>
> Conky will keep an internal list of all seen network interfaces, which
> is limited to 64. If the number of these interfaces exceeds this limit,
> conky will crash.
>
> While this limit is large enough for most usecases, on a system where
> interfaces often appear and disappear (for example by starting
> docker-images) conky will eventually run into that limit.
>
> The supplied patch avoids that issue by removing old network interfaces
> from the said internal list, once they disappear.

Please forward this patch upstream [1].

Regards,
Vincent

[1] https://github.com/brndnmtthws/conky

Bug#899496: f2fs-tools: Invalid maintainer address filesystems-de...@lists.alioth.debian.org

[Vincent Cheng]

Hi Christoph / alioth-lists maintainers,

On Thu, May 24, 2018 at 12:43 AM, Christoph Biedl
 wrote:
> Package: src:f2fs-tools
> Version: 1.10.0-1
> Severity: serious
> User: ad...@alioth-lists.debian.net
> Usertag: alioth-lists-maintainer
>
> Dear uploader of f2fs-tools,
>
> as you've probably heard, Debian's alioth services are shutting down.
> This affects your package f2fs-tools since the list address
> filesystems-de...@lists.alioth.debian.org used in the Maintainer: field
> was not transferred to the alioth-lists service that provides a
> continuation for the lists in the @lists.alioth.debian.org domain.
>
> Addresses that were not migrated have been disabled some time  ago. As
> a result your package is now in violation of a "must" in the Debian
> policy (3.3, working email address), making it unfit for release.
>
> Please fix this before long. Among other reasons, keep in mind bug
> reports and important notifications about your package might not reach
> you.
>
> Your options:
>
> * Upload another version with a new maintainer address of your choice,
>
> * Migrate the list to the new system. This is still possible,
>   please appoint a Debian developer as a list owner first, then
>   contact the alioth lists migration team 
>   and provide all the necessary information.
>
>   More information about the new service can be found here:
>   
>
> * More options, even if imperfect, can be found at
>   
>
>
> The first option is probably suitable only if the address was used just
> in a small number of packages since this requires an upload for each of
> them. To our knowledge, the usage count of
> filesystems-de...@lists.alioth.debian.org is 8.
>
> The second option is available for a limited time only, by end of
> May 2018 the most. So if you're interested in going this way, start the
> process as soon as possible.

I'd like to volunteer to be the list owner for the filesystems-devel
list and have the list migrated over to the alioth-lists service. What
information do I need to provide to complete this migration? Thank
you!

Regards,
Vincent

Bug#899279: RM: wesnoth-1.12,wesnoth-1.13 -- ROM; made obsolete by wesnoth-1.14

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

src:wesnoth-1.12 and src:wesnoth-1.13 have both been made obsolete by
wesnoth-1.14. Please remove these two packages.

Bug#868047: [Python-apps-team] Bug#868049: Intent to NMU: pelican/3.7.1+dfsg.1-1

[Vincent Cheng]

Hi Ben,

On Mon, Aug 7, 2017 at 4:24 PM, Ben Finney  wrote:
> Control: tags -1 + pending
>
> Given that both these (bug#868049, bug#868047) are Severity: serious,
> the ‘pelican’ package is scheduled for removal from “testing” very
> soon.
>
> I have a Git repository to develop release “3.7.1+dfsg.1-1”
> .
>
> If there is no substantive objection before my evening today (Tue
> 2017-08-08 UTC+10:00), I will do a Non-Maintainer Upload of the
> release I have prepared, incorporating the patches to fix these bugs
> to allow the package to remain.

NACK from maintainer.

Shipping a broken theme by default would be a disservice to our users
(yes, I consider replacing social media images in the default theme
with nondescript images to be completely broken behaviour for end
users of the package). I'd much rather see the "notmyidea" theme
removed from the package (which is probably what I'll end up doing to
fix #868047), or pelican removed from the archive entirely.

As a side note, I object to #868049 being considered a RC bug. The
specified HTML file in the bug,
pelican/themes/notmyidea/templates/base.html, isn't even a valid HTML
file; it's merely a jinja template that will fail to open in any
browser as-is, so there's no way it can breach the privacy of the user
who installed the package (the user is not even expected to open the
files as-is in a web browser, as opposed to say, documentation
provided by doc packages). Arguing that the referenced HTML file has
the potential to be privacy-breaching (and thus RC-buggy) when used to
generate a blog with pelican is akin to arguing that gcc is RC-buggy
because it can be used to compile non-free, privacy-breaching
software, or apache/nginx is RC-buggy because it can be used to serve
up non-free, privacy-breaching data.

Regards,
Vincent

Bug#860420: Secrets of the Ancients campaign is not packaged

[Vincent Cheng]

Control: tag -1 + pending

On Sun, Apr 16, 2017 at 8:13 AM, Evgeny Kapun  wrote:
> Source: wesnoth-1.13
> Version: 1:1.13.7-1
>
> Secrets of the Ancients is a new mainline campaign added to Wesnoth in
> version 1.13.7 [1]. It needs to be included in a Debian package.
>
> [1]
> https://raw.githubusercontent.com/wesnoth/wesnoth/1.13.7/players_changelog

Whoops, accidentally overlooked this when I was preparing 1.13.7-1 for
upload. I'm currently uploading -2 to the NEW queue, with a newly
added wesnoth-1.13-sota package. Thanks for the reminder!

Regards,
Vincent

Bug#814453: bijiben: High CPU usage after Gnome shell search

[Vincent Cheng]

Hi David,

On Fri, Apr 7, 2017 at 3:51 AM, David Ayers  wrote:

> How can I install the debug symbols for a proper backtrace?

You'll need to enable the dbgsym repository [1], and install bijiben-dbgsym.

Please forward this bug report and stacktrace upstream in bugzilla [2].

Thanks,
Vincent

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2] https://bugzilla.gnome.org/enter_bug.cgi?product=bijiben

Bug#859985: bijiben: Search provider not working?

[Vincent Cheng]

Hi Laurent,

On Sun, Apr 9, 2017 at 4:07 PM, Laurent Bigonville  wrote:
> Package: bijiben
> Version: 3.20.2-1+b3
> Severity: important
> Tags: patch
> Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=781106
>
> Hello,
>
> When gnome-shell is starting I can see the following line in the logs:
>
> JS LOG: Failed to add search provider
> /usr/share/gnome-shell/search-providers/org.gnome.bijiben-search-provider.ini:
> TypeError: appInfo is null
>
> Looking in the source I can see several places that reference the old
> .desktop file name (bijiben.desktop vs org.gnome.bijiben.desktop)
>
> The attached patch is fixing the error message in gnome-shell and the
> "Notes" search provider is now listed in gnome-control-center.
>
> This should be fixed for stetch IMHO.

Would you be able to take care of this bug with a NMU and following up
with an unblock request with the release team? I'm afraid I don't have
much time at the moment to do so myself.

Thanks,
Vincent

Bug#852230: unknown-horizons: have another program where dependencies are sorted out for unknown-horizons.

[Vincent Cheng]

On Sun, Jan 22, 2017 at 10:49 AM, Markus Koschany  wrote:
>> On 22.01.2017 19:30, shirish शिरीष wrote:
>>> Package: unknown-horizons
>>> Version: 2017.1+ds-2
>>> Severity: wishlist
>>>
>>> Dear Maintainer,
>>> Right now what happens is if there are any change/s to the depends or
>>> recommends then the unknown-horizons binary gets downloaded each time.
>>> This is waste of time and bandwidth from the user as well as Debian's
>>> server/mirror perspective.
>>>
>>> It would be much better and much more highly efficient (probably) if
>>> we have a small program which deals with all or any changes with
>>> depends or recommends.
>>>
>>> Unknown-horizons binary should only be disturbed when the change
>>> directly affects unknown-horizons, otherwise not.
>
> This is the way how it works in Debian and not a bug in unknown-horizons
> by the way. If you make a change to the source package regarding
> build-dependencies or dependencies then it must be rebuilt because
> information about dependencies are stored in your deb file.
>
> Your "small program" still needs to know what has changed and retrieve
> the information from somewhere, a database maybe. You need to implement
> this change so that all packages in the archive will continue to work.
> Not a small feat. You should discuss this with the maintainer(s) of dpkg
> or on a public mailing list. Unknown-Horizons is the wrong package though.

Strictly speaking, you can accomodate this request by splitting up
src:unknown-horizons into two separate source packages, one which
builds a binary deb that contains the game binary. the other which
builds a binary deb containing all the game data. The only issue with
this approach is that I personally hate mangling upstream source
tarballs, so I only do this if upstream releases separate source
tarballs for the game engine and data (e.g. src:0ad and src:0ad-data).
Punting it over to dpkg's side of the fence is unnecessary IMHO (and I
don't think there's anything reasonable that can be done on the dpkg
side of things that wouldn't be better implemented using the split
source package approach).

Regards,
Vincent

Bug#848001: supertuxkart: Fix credits for Boom-boom-boom song

[Vincent Cheng]

On Tue, Jan 3, 2017 at 2:56 AM, James Cowgill <jcowg...@debian.org> wrote:
> On 02/01/17 22:03, Vincent Cheng wrote:
>> On Thu, Dec 15, 2016 at 7:08 AM, Legimet <legimet.c...@gmail.com> wrote:
>>> Just to be clear, this affects the credits that show up after clicking the
>>> "About" button in the lower-right corner of the start screen. To fix it, the
>>> file data/CREDITS needs to be changed.
>>>
>>> On Monday, December 12, 2016 9:39:30 PM EST Legimet wrote:
>>>> Package: supertuxkart
>>>> Severity: normal
>>>>
>>>> In the credits (data/CREDITS), the Boom-boom-boom song should be
>>>> credited to its author, Keith Baylis aka Vim, rather than Matt Thomas.
>>
>> diff recognizes data/CREDITS as a binary file instead of a plain-text
>> ASCII file or similar; I can't generate a quilt patch to fix this. The
>> only way to fix this bug right now would be to repack the orig tarball
>> yet again, which I would rather not do. Given that this has already
>> been fixed upstream [1], I'm inclined to just wait for a new upstream
>> release instead.
>
> Couldn't you just install a new CREDITS file manually (overwriting the
> old one after dh_install)? I'm not saying that's the best idea, but you
> don't have to repack the tarball for this.

Ack, that's true. I suppose the only problem with that approach is if
I forget to remove the CREDITS file I added once a new upstream
release is made. I'd rather not have yet another thing on my todo list
to keep track of. ;)

Regards,
Vincent

Bug#848001: supertuxkart: Fix credits for Boom-boom-boom song

[Vincent Cheng]

On Thu, Dec 15, 2016 at 7:08 AM, Legimet  wrote:
> Just to be clear, this affects the credits that show up after clicking the
> "About" button in the lower-right corner of the start screen. To fix it, the
> file data/CREDITS needs to be changed.
>
> On Monday, December 12, 2016 9:39:30 PM EST Legimet wrote:
>> Package: supertuxkart
>> Severity: normal
>>
>> In the credits (data/CREDITS), the Boom-boom-boom song should be
>> credited to its author, Keith Baylis aka Vim, rather than Matt Thomas.

diff recognizes data/CREDITS as a binary file instead of a plain-text
ASCII file or similar; I can't generate a quilt patch to fix this. The
only way to fix this bug right now would be to repack the orig tarball
yet again, which I would rather not do. Given that this has already
been fixed upstream [1], I'm inclined to just wait for a new upstream
release instead.

Regards,
Vincent

[1] 
https://github.com/supertuxkart/stk-code/commit/ee17928382876226a0082d60458c6eb40e643d80

Bug#848551: f2fs-tools: please make an udeb

[Vincent Cheng]

Hi Adam,

On Sun, Dec 18, 2016 at 3:05 AM, Adam Borowski  wrote:
> Package: f2fs-tools
> Version: 1.7.0-1
> Severity: wishlist
> Tags: d-i
>
>
> Hi!
> On machines with flash storage (SD, eMMC) traditional filesystems behave
> abysmally bad:
>
> * "git reset --hard" of a big empty tree: btrfs 3m45s, f2fs 4m, ext4 12m, xfs
> 16-18m (big variance)
>
> * ./configure && make -j4 && make test" of a shit package with only ~2MB of
> persistent writes: f2fs 95s, btrfs 97s, xfs 120s, ext4 122s (where does this
> difference even come from, on a CPU-bound task with virtually no writeout?)
>
> So the real good options are btrfs and f2fs.  And btrfs is... quirky to say
> the least, having goodies like snapshots, data checksums or compression
> (great for speed if CPU is much faster than I/O) but also having serious
> reasons people may want to avoid it for.
>
> Adding d-i support, besides adding a menu item that's simple for a
> single-device filesystem, requires having an udeb with at least mkfs, other
> tools also being nice to have in case the user needs to troubleshoot during
> the installation.
>
> Thus, would you care creating such an udeb?  Apologies for waking up that
> late, it'd need to pass NEW no later than Xmas.

I have no time to work on this before the NEW freeze, but feel free to
NMU to have src:f2fs-tools build a udeb package, and whatever else is
required for d-i support.

Regards,
Vincent

Bug#847641: obnam: FTBFS on all archs due to test failure

[Vincent Cheng]

Source: obnam
Version: 1.20.2-1
Justification: fails to build from source (but built successfully in the past)
Severity: serious

I checked the BTS but it doesn't look like this has been reported
before; sorry if this is a duplicate report.

obnam currently FTBFS on all archs in sid (for about a month now);
relevant part of build log is as follows:


ERROR: In scenario "encrypted backup and restore with a separate keyring"
step "WHEN user U backs up directory L to repository R" failed,
with exit code 1:
Standard output from shell command:

Standard error from shell command:
+ run_obnam U backup -r
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/R
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/L
+ local name=U
+ shift
+ local 
conf=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ add_to_config U weak-random yes
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=weak-random
+ local value=yes
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n weak-random yes
+ add_to_config U lock-timeout 0
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=lock-timeout
+ local value=0
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n lock-timeout 0
+ [ -n 6 ]
+ add_to_config U repository-format 6
+ local client=U
+ local 
filename=/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
+ local key=repository-format
+ local value=6
+ [ ! -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
]
+ printf %s = %s\n repository-format 6
+ [ -e 
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.env
]
+ /«PKGBUILDDIR»/obnam --no-default-config --config
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/U.conf
--quiet --log-level debug --log
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/obnam.log
--trace obnamlib --trace larch backup -r
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/R
/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/L
ERROR: R0C79EX: gpg failed with exit code 2:
Command: gpg -q --batch --no-textmode -c --passphrase-fd 4
gpg: can't open '/usr/share/gnupg/dirmngr-conf.skel': No such file
or directory
gpg: new configuration file
'/tmp/tmpNm8AbD/encrypted_backup_and_restore_with_a_separate_keyring/datadir/HOME/.gnupg/gpg.conf'
created
gpg: can't connect to the agent: IPC connect call failed
gpg: problem with the agent: No agent running

Bug#832062: SuperTuxKart must be uploaded soon for not missing stretch

[Vincent Cheng]

Hi Joerg,

On Thu, Dec 1, 2016 at 5:00 PM, henrichsjo...@gmail.com
 wrote:
> Hi all,
>
> I am one of the STK admins. Can you tell us exactly what you need? The song
> was released under CC-BY-SA by the author (as indicated by the author's
> email we received, which we published in the mentioned forum thread:
> http://forum.freegamedev.net/viewtopic.php?f=17=6562#p70981).
>
> Afaik under CC-BY-SA no 'source code' is necessary, but even so the .mod
> file is available in our media repo
> (https://svn.code.sf.net/p/supertuxkart/code/media/trunk/music/mods/).
>
> I am not really sure what else you need - any advise appreciated!

I don't think there's anything else we expect from upstream to resolve
this bug. I was hoping for the author (vimster) to release some sort
of public, verifiable statement that they would like to license their
works under CC-BY-SA, in order to refute their earlier statement in
that same forum thread that they want their work to be licensed with a
not-for-profit clause (I'm assuming that would be something akin to
CC-BY-SA-NC, which would not be considered DFSG-free by Debian). But
I'm fine with taking deve's word that the author accepted CC-BY-SA
licensing in a private email. Thanks for getting in touch with the
author and clarifying the license!

My hesitation with this bug was mostly due to uncertainty whether
Debian's ftpmasters and/or other maintainers within the Debian Games
team would require more proof regarding the author's intentions, but
that does not seem to be the case. Assuming no objections from the
team, I'll prepare a STK upload over the weekend.

> PS: Is there a way of avoiding publishing email addresses here on the web
> site? It's too late now for me, but maybe for next time ;)

Unfortunately not, but if you contact me directly off-list, I'll still
do my best to reply ASAP. :)

Regards,
Vincent

Bug#832062: SuperTuxKart must be uploaded soon for not missing stretch

[Vincent Cheng]

On Wed, Nov 30, 2016 at 10:13 AM, Adrian Bunk <b...@stusta.de> wrote:
> On Mon, Nov 28, 2016 at 11:57:00PM -0800, Vincent Cheng wrote:
>> Hi Adrian,
>
> Hi Vincent,
>
>> On Mon, Nov 28, 2016 at 10:53 AM, Adrian Bunk <b...@stusta.de> wrote:
>> > Hi,
>> >
>> > if I undererstand it correctly, all 3 RC bugs in SuperTuxKart have been
>> > resolved upstream.
>>
>> The status of #832062 is not so clear-cut. I think it's open to
>> interpretation whether the file in question in that bug report is
>> actually available for use under a DFSG-compatible license, which is
>> why I looped in ftpmasters in the bug report (see my reply at [1] for
>> my understanding of the current situation), but have not received any
>> sort of response. I'm willing to take upstream's word about the sound
>> file's DFSG compatibility, but would like to get a ACK/NACK from
>> someone authoritative (i.e. ftpmasters).
>>...
>
> Scott Kitterman from the ftpmaster team commented when I asked on IRC:
>
> 10:44 < ScottK> bunk: I think the maintainer has it handled.  He ought to use
> his best judgment instead of hesitating.  I don't see anyone
> objecting.  i don't think the FTP team needs to get involved.
>

Fair enough. I'll go ahead and prepare a STK upload over the weekend,
unless anyone on the team has any last minute objections.

Regards,
Vincent

Bug#832062: SuperTuxKart must be uploaded soon for not missing stretch

[Vincent Cheng]

Hi Adrian,

On Mon, Nov 28, 2016 at 10:53 AM, Adrian Bunk  wrote:
> Hi,
>
> if I undererstand it correctly, all 3 RC bugs in SuperTuxKart have been
> resolved upstream.

The status of #832062 is not so clear-cut. I think it's open to
interpretation whether the file in question in that bug report is
actually available for use under a DFSG-compatible license, which is
why I looped in ftpmasters in the bug report (see my reply at [1] for
my understanding of the current situation), but have not received any
sort of response. I'm willing to take upstream's word about the sound
file's DFSG compatibility, but would like to get a ACK/NACK from
someone authoritative (i.e. ftpmasters).

> SuperTuxKart is currently not in testing, and if a fixed version does
> not get uploaded soon it will miss the stretch release.

STK cannot migrate to testing until #832062 is resolved.

Regards,
Vincent

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832062#37

Bug#846038: wesnoth: Setting fullscreen crashes game

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

Hi,

On Sun, Nov 27, 2016 at 6:12 PM, Alex Henry  wrote:
> Package: wesnoth
> Version: 1:1.12.6-1
> Severity: important
> Tags: upstream
>
> Hello! As the title says whenever I select "fullscreen" the game
> simply dies on me. The following is output to the console:
>
> setting mode to 1024x768x32
> X Error of failed request:  BadValue (integer parameter out of range for 
> operation)
>   Major opcode of failed request:  152 (XFree86-VidModeExtension)
>   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
>   Value in failed request:  0x49e
>   Serial number of failed request:  196
>   Current serial number in output stream:  198
>
> I am using KDE5 and I believe that Debian is using Wayland on top of X.org
> or something like that.
>
> I'm setting this as important because I imagine most people like
> to play games fullscreen but it is a matter of opinion really. If
> you think this should prevent the game from reaching stable I
> believe you'd have to change it to a higher severity.

I can't reproduce this bug myself; I have always been able to run
wesnoth in windowed or fullscreen mode without a problem.

My guess is that this is some sort of bug specific to certain
fullscreen resolutions (probably more esoteric ones). There are
mentions of this issue in the wesnoth forums, e.g. [1], so probably
not an isolated issue, but I don't think it's widespread enough to
justify a severity bump. Please try and see if this is reproducible
with wesnoth-1.13, and also consider filing a bug report upstream [2].

Regards,
Vincent

[1] https://forums.wesnoth.org/viewtopic.php?t=43576=592233
[2] https://wiki.wesnoth.org/Reportingbugs

Bug#845223: 0ad: Crashes on startup with cache.cpp(43): Assertion failed: "cache.Validate()"

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

Hi,

On Mon, Nov 21, 2016 at 8:35 AM,   wrote:
> Package: 0ad
> Version: 0.0.21-2
>
> Hiya,
>
> I just installed 0ad on my system.
> It crashes as soon as I start the game.
> See attachment for crash log. If I say "go on", it manages to play the
> music.
>
> note: I thought there was a -dbg package, but not in my repos.

0ad has now migrated to using auto-generated dbgsym packages (like
many other packages in Debian sid). You'll have to add an additional
line to your sources.list to pick up the dbgsym repository [1].

Please file a bug report upstream after obtaining a backtrace at [2].

Regards,
Vincent

[1] https://lists.debian.org/debian-devel/2015/12/msg00262.html
[2] http://trac.wildfiregames.com/newticket

Bug#844384: RM: 0ad [arm64] -- ROM; FTBFS on specific archs

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Please remove 0ad on arm64. It's unlikely to be fixed by upstream
since it's caused by 3rd-party code (spidermonkey/mozjs), and time
could be better spent elsewhere since there are likely zero users of
the package on arm64 anyways.

Regards,
Vincent

Bug#841198: conky-all: please enable PulseAudio

[Vincent Cheng]

Control: tag -1 + pending

Hi Kevin,

On Tue, Oct 18, 2016 at 6:06 AM, Kevin Velghe  wrote:
> Please build conky-all, and maybe some other builds, with PulseAudio
> support enabled, which has been added in 1.10.3.

Thanks for the patch; I've committed it to svn and will be fixed in
the next upload.

Regards,
Vincent

Bug#832062: supertuxkart: source for GPL song Boom_boom_boom.ogg missing

[Vincent Cheng]

(Looping in ftpmasters to see if they have any comments re: #832062)

Hi Deve,

On Tue, Oct 4, 2016 at 1:19 PM, Deve  wrote:
> Hi,
>
> After direct contact with the author, I corrected the information about
> author and license in this commit:
>
> https://sourceforge.net/p/supertuxkart/code/16762/
>
> Also note that source files (the .mod file and lossless .wav file) are
> available in our media repo:
> https://sourceforge.net/p/supertuxkart/code/HEAD/tree/media/trunk/music/mods/

Great, thanks for the link!

> More information:
> http://forum.freegamedev.net/viewtopic.php?f=17=6562
> https://github.com/supertuxkart/stk-code/issues/2577
>
> I hope that this should be enough to fix this issue.

Would it be at all possible for "Vim" to publicly state their approval
of licensing "Boom_boom_boom.ogg" under the CC-BY-SA 4.0 license (by
replying directly to this bug report / upstream github issue / forum
thread at [1])? Unfortunately their last public statement in [1]
imposes a not-for-profit condition on using their work, which violates
DFSG#6.

Does ftpmaster or anyone else in the Debian Games team have any
thoughts about this issue? I think a public statement from the
original composer of the track in question would be sufficient (unless
"Vim" has a gpg key tied to their identity, which doesn't seem to be
the case), unless anyone has any objections? I don't think we can
reasonably expect more proof from upstream that this file is
DFSG-compatible.

Regards,
Vincent

[1] http://forum.freegamedev.net/viewtopic.php?f=17=6562#p70981

Bug#811724: Info received (supertuxkart: FTBFS with GCC 6: narrowing conversion)

[Vincent Cheng]

On Wed, Sep 28, 2016 at 8:46 AM, James Cowgill  wrote:

> #832062 - Boom_boom_boom.ogg no source for GPL

AFAIK, this bug has yet to be resolved upstream, and also affects
0.9.1, so even if the gcc FTBFS bug were to be fixed, STK 0.9.1
wouldn't be able to migrate to testing.

Regards,
Vincent

Bug#838055: 0ad: Embedded libsquish library now available in debian

[Vincent Cheng]

Control: block -1 by 838056

Hi Wookey,

On Fri, Sep 16, 2016 at 5:46 PM, Wookey  wrote:

>- nvidia-texture-tools 1.7 (src/nvtt/squish)
>- 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/)

0ad actually embeds a copy of nvidia-texture-tools, which in turn
embeds a copy of libsquish. Since we build 0ad with Debian's
nvidia-texture-tools packages and not with the embedded copy, there's
nothing that needs to be done in 0ad; once nvidia-texture-tools
switches over to using libsquish as packaged in Debian, 0ad will also
be using the system version as well. Thanks for the bug report anyhow!

Regards,
Vincent

Bug#836250: transition: gloox

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hi,

I'd like to request a transition slot for src:gloox. This is a relatively small
transition, with only 2 source packages affected, both of which aren't
in testing so this bug report might be completely unnecessary (I guess
this bug could be considered a binNMU request for 0ad instead):

0ad (not in testing due to RC bug in dependency, #811612)
uwsgi (FTBFS, #828785 and #833055)

Ben file:

(https://release.debian.org/transitions/html/auto-gloox.html is accurate)

Regards,
Vincent

Bug#835176: pyrogenesis segfault

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Mario,

On Tue, Aug 23, 2016 at 3:06 AM,   wrote:
> Package: 0ad
> Version: 0.0.20-2
>
>  Good morning.
> As I wrote in the title of the message 0ad goes to segfault.
> This happens while I am playing and not at startup. It can happen after 1
> minute that I started playing or after 10 minutes.
> This is what I see in/var/log/messages:
>
> Aug 22 18:48:35 barambani kernel: [15176.276381] pyrogenesis[7714]: segfault
> at 0 ip 7f7588a44b38 sp 7ffc6e863110 error 4 in
> libmozjs31-ps-release.so[7f75888b6000+691000]
> Aug 22 19:06:51 barambani kernel: [16273.024162] pyrogenesis[7739]: segfault
> at 0 ip 7ff29086fb38 sp 7ffd86b33e80 error 4 in
> libmozjs31-ps-release.so[7ff2906e1000+691000]
> Aug 22 19:16:31 barambani kernel: [  509.739843] pyrogenesis[3124]: segfault
> at 0 ip 7fc711dcbb38 sp 7ffc87aa8e60 error 4 in
> libmozjs31-ps-release.so[7fc711c3d000+691000]
> Aug 23 11:36:54 barambani kernel: [ 4547.081516] pyrogenesis[6240]: segfault
> at 0 ip 7f35107d2b38 sp 7ffe5cb5ac00 error 4 in
> libmozjs31-ps-release.so[7f3510644000+691000]
>
> and in /var/log/dpkg.log
>
> 2016-08-21 15:35:53 upgrade 0ad:amd64 0.0.20-1+b2 0.0.20-2

Please obtain a backtrace (see instructions at [1]) and file a bug
report upstream at [2]. Thanks!

Regards,
Vincent

[1] https://wiki.debian.org/HowToGetABacktrace
[2] http://trac.wildfiregames.com/newticket

Bug#830751: supertuxkart-data: contains Ubuntu Font Family fonts

[Vincent Cheng]

Package: supertuxkart-data
Version: 0.9.2-1
Severity: serious
Justification: non DFSG file in the source package

supertuxkart/0.9.2-1 ships with the following files in the source tarball:

data/ttf/Ubuntu-B.ttf
data/ttf/Ubuntu-R.ttf

...which get installed into binary package supertuxkart-data:

/usr/share/games/supertuxkart/data/ttf/Ubuntu-B.ttf
/usr/share/games/supertuxkart/data/ttf/Ubuntu-R.ttf

These ttf files are Ubuntu Font Family fonts, which are not
DFSG-compatible as per ftpmasters' decision [1], with rationale
provided at [2]; further discussion can be found at [3]. These fonts
files will need to be replaced in Debian; I intend to also forward
this bug report upstream.

Regards,
Vincent

[1] 
http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2011-April/006515.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157#30
[3] https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874

Bug#830748: supertuxkart: FTBFS on arm64, mips/mips64/mipsel, ppc64el, s390x

[Vincent Cheng]

Package: supertuxkart
Version: 0.9.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

supertuxkart/0.9.2-1 FTBFS on arm64, mips/mips64/mipsel, ppc64el, and
s390x; full build log at [1], and here's the relevant part of the log:

[  9%] Building CXX object
lib/irrlicht/CMakeFiles/stkirrlicht.dir/source/Irrlicht/CGUIMeshViewer.cpp.o
cd /«PKGBUILDDIR»/obj-aarch64-linux-gnu/lib/irrlicht && /usr/bin/c++
-DGLEW_NO_GLU -DIRRLICHT_EXPORTS=1 -DNDEBUG=1
-DNO_IRR_LINUX_X11_VIDMODE_ -DPNG_NO_MMX_CODE -DPNG_NO_MNG_FEATURES
-DPNG_THREAD_UNSAFE_OK -D_IRR_LINUX_X11_RANDR_
-I/«PKGBUILDDIR»/lib/bullet/src -I/«PKGBUILDDIR»/lib/glew/include
-I/«PKGBUILDDIR»/lib/irrlicht/include  -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Wall -pipe -O3  -fno-exceptions  -fstrict-aliasing
-I/usr/X11R6/include -Wall -pipe -O3  -fno-exceptions
-fstrict-aliasing -I/usr/X11R6/include -fexpensive-optimizations -O2
-DNDEBUG   -o CMakeFiles/stkirrlicht.dir/source/Irrlicht/CGUIMeshViewer.cpp.o
-c /«PKGBUILDDIR»/lib/irrlicht/source/Irrlicht/CGUIMeshViewer.cpp
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp: In
function 'asQWORD X64_CallFunction(const asQWORD*, int, funcptr_t,
asQWORD&, bool)':
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%rcx' in 'asm'
 "%rdi", "%rsi", "%rax", "%rdx", "%rcx", "%r8", "%r9", "%r10",
"%r11", "%r15");

   ^
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%rdx' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%rax' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%rsi' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%rdi' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm7' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm6' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm5' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm4' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm3' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm2' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm1' in 'asm'
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc_x64_gcc.cpp:162:82:
error: unknown register name '%xmm0' in 'asm'


It looks like angelscript is misdetecting certain architectures as x86
and hence applying the wrong assembly directives. It's worth checking
first to see if there's a fix for this in upstream angelscript before
fixing it in supertuxkart. I'll take a look at this when I have time,
but help is greatly appreciated if someone has a chance to tackle this
before I do.

Regards,
Vincent

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

Bug#534058: build-depends not available on amd64

[Vincent Cheng]

Hi Steve,

On Sat, Jul 9, 2016 at 11:47 PM, Steve Langasek
 wrote:
> Package: pixbros
> Version: 0.6.3-2
> Followup-For: Bug #534058
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu yakkety ubuntu-patch
>
> Hello,
>
> There is now a provisional field that you can include in debian/control to
> indicate which architecture an architecture: all package needs to be built
> on: XS-Build-Indep-Architecture.
>
> Since amd64 is now the de facto default architecture used everywhere for
> building packages, and the build-dependencies of pixbros are only available
> on 32-bit architectures, it would be helpful to document this architecture
> requirement in the source package by, e.g., 'XS-Build-Indep-Architecture: 
> i386'.
>
> I've made this change in Ubuntu in order to allow the package to autobuild;
> please consider applying it in Debian as well.

This isn't directly related to pixbros, but last month I applied a
similar patch that you offered for pixfrogger in #534063 which also
added this new 'XS-Build-Indep-Architecture: i386' field. However, it
doesn't look like it works as intended, because while it does allow
the package to be autobuilt, the resulting package gets stuck in
-proposed (in Ubuntu); see LP: #1585058. Do you know what needs to be
done to get pixfrogger et al. to migrate properly?

Regards,
Vincent

Bug#811787: On irrlicht and RC bug #811787

[Vincent Cheng]

On Wed, Jul 6, 2016 at 8:46 AM, Gianfranco Costamagna
 wrote:
> control: tags -1 pending
> control: tags -1 patch
>
>>>Shall I turn it in a NMU or do you maintainers/uploaders have something
>>>ready to shoot?
>>
>>
>>I guess a team upload is perfectly fine!
>>I'll do it in a few hours if nobody objects, thanks a lot for the fix!
>
>
> Added team upload, changed versioning to -2, pushed on deferred/2 and on git 
> (--tags)

I would've been ok with this being uploaded straight to unstable, but
I suppose it's a moot point now that it's been (almost) 2 days. Either
way, thanks for taking care of the upload!

BTW, Julien, there's another RC bug against minetest (#829150) in case
you weren't already aware of it (I'm assuming your interest in
irrlicht is because minetest depends on it).

Regards,
Vincent

Bug#829525: [PATCH] 1.15 requires libdrm-dev >= 2.4.64

[Vincent Cheng]

Control: tag -1 + pending

On Sun, Jul 3, 2016 at 6:48 PM, Nicholas D Steeves  wrote:
> Package: intel-gpu-tools
> Version: 1.15-1
>
> I'm working on backporting intel-vaapi-driver to Jessie; it depends on
> intel-gpu-tools (>= 1.9) so I'm also working on backporting
> intel-gpu-tools.  I discovered that intel-gpu-tools-1.15 requires
> libdrm-dev >= 2.4.64.  Patch attached!
>
> Thank you,
> Nicholas

Applied, thanks for the patch.

Regards,
Vincent

Bug#828640: conky: Segmentation fault at start (conky 10.10.2)

[Vincent Cheng]

Control: tags -1 + moreinfo unreproducible

Hi,

On Sun, Jun 26, 2016 at 9:03 AM, markus  wrote:
> Package: conky
> Version: 1.10.2-1
> Severity: important
>
> Dear Maintainer,
>
> when I start conky, I imediately get a segmentation fault error.
> - standard configuration, nothing changed
>
> ___
>
> $conky --version
> conky 1.10.2 compiled Wed May  4 00:32:04 UTC 2016 for Linux 
> 3.16.0-4-powerpc64
> ppc

This must be the first powerpc-specific bug report I've ever received. :)

Please get a backtrace with gdb (see [1] for step by step instructions
if you're not familiar with the process) and report this bug upstream
at [2]. Thanks!

Regards,
Vincent

[1] https://wiki.debian.org/HowToGetABacktrace
[2] https://github.com/brndnmtthws/conky/issues/new

Bug#826379: codeblocks: incompatibility between GPL and RSA md5 license makes package non-distributable

[Vincent Cheng]

Source: codeblocks
Version: 16.01+dfsg-1
Severity: serious
X-Debbugs-CC: g...@debian.org

Codeblocks is licensed under GPL v3, but some files in the source
tarball contain code that is licensed as per the terms of RSA Data
Security, Inc.'s MD5 Message Digest Algorithm; this license is as
follows:

src/plugins/contrib/source_exporter/wxPdfDocument/src/pdfencrypt.cpp
src/plugins/contrib/source_exporter/wxPdfDocument/src/pdfxml.cpp

/*
 **
 ** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **
 **  **
 ** License to copy and use this software is granted provided that   **
 ** it is identified as the "RSA Data Security, Inc. MD5 Message **
 ** Digest Algorithm" in all material mentioning or referencing this **
 ** software or this function.   **
 **  **
 ** License is also granted to make and use derivative works **
 ** provided that such works are identified as "derived from the RSA **
 ** Data Security, Inc. MD5 Message Digest Algorithm" in all **
 ** material mentioning or referencing the derived work. **
 **  **
 ** RSA Data Security, Inc. makes no representations concerning  **
 ** either the merchantability of this software or the suitability   **
 ** of this software for any particular purpose.  It is provided "as **
 ** is" without express or implied warranty of any kind. **
 **  **
 ** These notices must be retained in any copies of any part of this **
 ** documentation and/or software.   **
 **
 */

This license is problematic for codeblocks because while it is free /
DFSG-compatible, it contains an advertising clause akin to the
original / 4-clause BSD license that renders it incompatible with the
GPL, which is what the majority of codeblocks' codebase is licensed
under. The GNU project has documented this incompatibility at [1].
There's also some discussion of this issue on debian-legal [2].

The RSA md5 license only applies to code used by the exporter plugin
in codeblocks, so we can avoid shipping a non-distributable codeblocks
package merely by not including that plugin (no DFSG violation here,
no need to repack source tarball). This is what I plan to do until
upstream replaces the current md5 implementation with one that does
not happen to be GPL-incompatible.

Regards,
Vincent

[1] http://www.gnu.org/licenses/license-list.html#OriginalBSD
[2] https://lists.debian.org/debian-legal/2016/05/msg00011.html

Bug#534063: pixfrogger: FTBFS: Nonexistent build-dependency: fenix

[Vincent Cheng]

On Thu, Jun 2, 2016 at 8:42 PM, Jeremy Bicha  wrote:
> I think this patch was wrong. Although it enabled the package to build
> on Ubuntu, it didn't enable the package to migrate out of the
> -proposed repository Ubuntu uses. I'm guessing that's because it fails
> basic install-ability checks.
>
> Since pixfrogger is only installable on i386, I think the binary
> Architecture field should be set to i386.
>
> I don't think you need the XS-Build-Indep-Architecture line then.

I disagree. The package is arch:all because it doesn't contain any
arch-specific files, and it would be installable on all architectures
if its dependencies are also installable on all archs. Listing out all
the archs that pixfrogger can run on (i.e. all non amd64 archs) would
just result in duplication across the archive for no particular
benefit.

The fact that it fails to migrate from proposed to release in Ubuntu
sounds more like an issue with whatever software Ubuntu is using for
testing package migrations.

Regards,
Vincent

Bug#824384: clearsilver: FTBFS: /usr/share/cdbs/1/class/python-module.mk:54: *** unterminated call to function 'strip': missing ')'. Stop.

[Vincent Cheng]

Hi Chris,

I can't reproduce this FTBFS at all using an up-to-date pbuilder sid
chroot. According to your build log:

>  Get:10 http://httpredir.debian.org/debian sid/main amd64 cdbs all 0.4.132 
> [79.1 kB]

That might be the culprit. It looks like cdbs has gone through a lot
of changes in sid in the last month, and using a newer version of cdbs
should make this FTBFS go away. Can you please try a rebuild with
cdbs/0.4.137 installed?

Regards,
Vincent

Bug#803547: bbswitch: please make the build reproducible

[Vincent Cheng]

Hi Luca,

On Sun, May 29, 2016 at 5:27 AM, Luca Boccassi  wrote:
> Control: -1 tags pending
>
> On Sat, 2015-10-31 at 10:56 +0100, Reiner Herrmann wrote:
>> Source: bbswitch
>> Version: 0.8-2
>> Severity: wishlist
>> Tags: patch
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: umask
>> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>>
>> Hi!
>>
>> While working on the "reproducible builds" effort [1], we have noticed
>> that bbswitch could not be built reproducibly.
>> The permissions inside a tarball vary because of different umasks.
>>
>> The attached patch tells tar to normalize the permissions.
>>
>> Regards,
>>  Reiner
>>
>> [1]: https://wiki.debian.org/ReproducibleBuilds
>
> Hello Reiner,
>
> Thanks for the patch, Vincent has applied it to Git so it will be in the
> next upload.
>
> I had noticed that the CI was reporting this problem for i386/armhf, but
> hadn't got around to look into it yet.
>
> Andreas, Vincent,
>
> There is movement again upstream but I don't think there will be a new
> release soon, and I don't think we have anything pending ourselves, so
> IMHO we can upload this already.

Ok, I've gone ahead and uploaded bbswitch a few minutes ago.

> I'm happy to take care of it, if one of you whitelists my key for the
> package. Thanks!

Of course. :)

Regards,
Vincent

Bug#646693: hunspell-en-us conflicts with thunderbird because of missing version specifier

[Vincent Cheng]

Hi Rene,

> This package's control file still contains a Conflicts line which ends
> in thunderbird without specifying a version, causing thunderbird to be
> removed upon installation of hunspell-en-us. The same goes for several
> (all? I only checked a few) other hunspell dictionary packages.

Now that iceweasel has been renamed to firefox and icedove is going to
be renamed back to thunderbird at some point in the future (#816679),
would you reconsider adding a versioned "conflicts: thunderbird"
relationship in hunspell-en-us instead of the current unconditional
conflicts declaration? Thanks!

Regards,
Vincent

Bug#821043: wesnoth-1.13-core: fails to upgrade: update-alternatives: error: alternative link /usr/share/man/de/man6/wesnoth.6.gz is already managed by wesnoth.de.6.gz (slave of wesnoth)

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

On Thu, Apr 14, 2016 at 3:10 PM, Axel Beckert  wrote:
> Package: wesnoth-1.13-core
> Version: 1:1.13.4-1
> Severity: serious
>
> Hi,
>
> trying to upgrade wesnoth-1.13-core from 1:1.13.2-1 to 1:1.13.4-1 fails
> as follows:
>
> Setting up wesnoth-1.13-core (1:1.13.4-1) ...
> update-alternatives: error: alternative link 
> /usr/share/man/de/man6/wesnoth.6.gz is already managed by wesnoth.de.6.gz 
> (slave of wesnoth)
> dpkg: error processing package wesnoth-1.13-core (--configure):
>  subprocess installed post-installation script returned error exit status 2
> Errors were encountered while processing:
>  wesnoth-1.13-core
>
> Accordingly all packages depending on wesnoth-1.13-core fail as well.
>
> Please note that wesnoth-1.12 is also installed. Current state of all
> wesnoth-related packages on this system:

I can't reproduce this error at all. I had no issues upgrading from
wesnoth-1.13 1.13.2-1 to 1.13.4-1 on my own system, with wesnoth-1.12
installed at the same time. I also can't reproduce this in a clean
pbuilder chroot, i.e.:

# pbuilder --create --distribution sid --mirror http://ftp.ca.debian.org/debian
# pbuilder login
# apt-get install wesnoth-1.12
# echo "deb http://snapshot.debian.org/archive/debian/20160331T221016Z/
experimental main" > /etc/apt/sources.list.d/exp.list
# apt-get -o Acquire::Check-Valid-Until=false update
# apt-get install wesnoth-1.13 # installs 1.13.2-1 from snapshot.d.o
# echo "deb http://ftp.ca.debian.org/debian experimental main" >
/etc/apt/sources.list.d/exp.list
# apt-get update
# apt-get dist-upgrade # installs 1.13.4-1 successfully

And piuparts doesn't report any installation errors either [1],
although I suppose the piuparts.d.o reports don't mean much since it's
just testing clean installs of 1.13.4-1, not upgrades from 1.13.2-1 to
1.13.4-1.

I didn't change anything in any of the maintscripts when I updated the
packaging for wesnoth-1.13 1.13.4-1, so I'm frankly stumped as to why
you're seeing this error. Rhonda, any ideas?

Regards,
Vincent

[1] 
https://piuparts.debian.org/experimental/maintainer/v/vch...@debian.org.html#wesnoth-1.13

Bug#815641: geary: please package the new fork of geary

[Vincent Cheng]

On Tue, Feb 23, 2016 at 1:00 AM, Kristof Csillag
 wrote:
> Package: geary
> Severity: wishlist
>
> The package hasn't been updated for almost a year now,
> because upstream development has ceased.
>
> Quoting to the wikipedia page for geary,
> https://en.wikipedia.org/wiki/Geary_(software)
>
>> As Yorba Foundation stopped its activities and the future
>> of this application was unclear, elementary OS still using
>> this email client by default, has decided to fork the project
>> on November 18, 2015, renaming the project to Pantheon Mail
>> during the process.
>
> Maybe Debian could also ship the fork, which is under active
> development?

There seems to be activity on the mailing list, as well as potentially
new maintainers stepping up to take care of geary [1]. In light of
this, I don't think it's appropriate to ship the eOS fork as geary;
rather, I think Pantheon Mail should be packaged separately.

Regards,
Vincent

[1] https://mail.gnome.org/archives/geary-list/2016-March/msg2.html

Bug#815639: geary: Geary won't start

[Vincent Cheng]

On Tue, Feb 23, 2016 at 12:39 AM, Kristof Csillag
 wrote:
> Package: geary
> Version: 0.10.0-1
> Severity: important
>
> When I try to launch geary, I get this:
>
> user@host:~$ geary
>
> (geary:17024): GLib-GIO-ERROR **: Settings schema 'org.yorba.geary' does not 
> contain a key named 'composer-pane-position'
> Trace/breakpoint trap
>
> and the it exits.
>
> The same version of geary (0.10.0) works for me if I compile it myself,
> this only happens with the debian package.
>
> It would be great if it could be fixed.

I'm unable to reproduce this; geary/0.10.0-1 launches fine for me on
my current testing/sid system, without needing to be rebuilt. You
shouldn't expect packages from sid to function on a stable system
as-is; re-building it in a stable environment/chroot before being able
to use a given package on stable is often necessary, assuming that's
what you're trying to achieve.

Regards,
Vincent

Bug#781501: gnote segfaults when it can't find a .note file

[Vincent Cheng]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=765791

Hi Michael,

On Sun, Apr 17, 2016 at 3:46 PM, Michael Biebl  wrote:
> Control: severity -1 grave
> Control: tags -1 - moreinfo unreproducible
>
> Hi Vincent
>
> Am 18.04.2016 um 00:35 schrieb Michael Biebl:
>>
>> I can reproduce the issue (backtrace attached).
>>
>> I do have a ~/.gnote folder. gnote has been installed a long time.
>> Moving ~/.gnote away, makes gnote start up.
>>
>> I do think this makes it a RC bug, as gnote should be able to deal with
>> old data after an upgrade.
>
> Here is a simple way to reproduce the bug:
>
> # remove existing data
> rm -rf ~/.local/share/gnote
> # create some legacy data
> mkdir ~/.gnote
> then copy the attached file to ~/.gnote/
>
> If you now start gnote, you'll get the crash. In the light of this
> simple reproducer and assuming that there are possibly quite a few users
> with old data, I'm raising the severity.

Thanks, I can reproduce it now. It seems like you don't even need
legacy data to trigger this segfault; any note file will do (I tried
with some of my current note files), so long as neither
$XDG_CONFIG_HOME/gnote or $XDG_DATA_HOME/gnote are present.

Regards,
Vincent

Bug#822921: uwsgi: FTBFS with latest apache2

[Vincent Cheng]

Source: uwsgi
Version: 2.0.12-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

uwsgi currently FTBFS in sid. It looks like it might have something to
do with recent changes in apache2, because uwsgi builds fine with
apache2-dev/2.4.18-2 installed, but FTBFS with apache2-dev/2.4.20-1
(currently in sid). Buildd logs show that uwsgi FTBFS after having
been binNMU-ed for the gloox transition, but uwsgi actually builds
fine with either version of gloox (1.0.13-3 or 1.0.15-2) as long as
the older version of apache2-dev is installed, so this FTBFS wasn't
caused by the gloox transition.

buildd logs can be found at [1] as usual, tail as follows:

apache2/mod_proxy_uwsgi.c:262:21: error: static declaration of
'ap_proxy_buckets_lifetime_transform' follows non-static declaration
 static apr_status_t ap_proxy_buckets_lifetime_transform(request_rec *r,
 ^
In file included from apache2/mod_proxy_uwsgi.c:50:0:
/usr/include/apache2/mod_proxy.h:1069:29: note: previous declaration
of 'ap_proxy_buckets_lifetime_transform' was here
 PROXY_DECLARE(apr_status_t) ap_proxy_buckets_lifetime_transform(request_rec *r,
 ^
apxs:Error: Command failed with rc=65536

Regards,
Vincent

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

Bug#822744: transition: gloox

[Vincent Cheng]

On Wed, Apr 27, 2016 at 12:12 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> Control: tags -1 confirmed
>
> On 27/04/16 03:59, Vincent Cheng wrote:
>> Package: release.debian.org
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Severity: normal
>>
>> Hi,
>>
>> I'd like to request a transition slot for src:gloox. This is a relatively 
>> small
>> transition, with only 3 source packages affected (tested builds against newer
>> gloox, currently in experimental, results are as follows):
>>
>> licq (FTBFS not related to gloox, #820106, pending autoremoval)
>> 0ad (build ok, needs binNMU)
>> uwsgi (build ok, needs binNMU)
>
> Go ahead.

Uploaded, built and installed on all archs. Thanks in advance for
scheduling binNMUs!

Regards,
Vincent

Bug#822744: transition: gloox

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hi,

I'd like to request a transition slot for src:gloox. This is a relatively small
transition, with only 3 source packages affected (tested builds against newer
gloox, currently in experimental, results are as follows):

licq (FTBFS not related to gloox, #820106, pending autoremoval)
0ad (build ok, needs binNMU)
uwsgi (build ok, needs binNMU)

Ben file:

(https://release.debian.org/transitions/html/auto-gloox.html is accurate)

Regards,
Vincent

Bug#822330: bumblebee : unable to work with any newer driver than 340.96 - even backported bumblebee-nvidia install doesn't work (failed to set DRM interface version 1.4 too)

[Vincent Cheng]

Hi Luca,

On Sun, Apr 24, 2016 at 6:04 AM, Luca Boccassi  wrote:

> I can only assume at this point that the issue is hardware-specific.

Yep, sounds like it's indeed hardware-specific.

> I'll document this workaround in the debian/README.source, not much else
> we can do I'm afraid.

Probably not d/README.source, since that doesn't actually get shipped
in the binary package. This specific workaround is actually already
documented in d/README.Debian and on the Debian wiki entry for
bumblebee [1].

Regards,
Vincent

[1] https://wiki.debian.org/Bumblebee

Bug#822330: bumblebee : unable to work with any newer driver than 340.96 - even backported bumblebee-nvidia install doesn't work (failed to set DRM interface version 1.4 too)

[Vincent Cheng]

Hi Julien,

On Sat, Apr 23, 2016 at 4:15 PM, Julien ROBIN  wrote:
> Hi Luca,
>
> It's interesting that you can get it working, it's also a little bit 
> surprising : it means that there is something wrong with my hardware or 
> software settings - and for setting the entire system, I followed the very 
> most straightforward standard installation... anyway, hard or soft, let's 
> investigate :
>
> Here is the additional information :
>
> The command "reportbug -N 822330 nvidia-driver" gives nothing, after less 
> than 1 second it closes without saying anything.

reportbug's GUI can be a bit buggy; I suggest using the text interface
instead if it crashes for you (sed -i 's/ui gtk2/ui text/g'
~/.reportbugrc).

> In compensation, here is attached to this email, syslog content and 
> Xorg.8.log, it's telling a lot of things but as I know that a lot of warning, 
> errors etc are "normal" or common to all kind of different problems source, I 
> let you investigate !

>From your Xorg.8.log:

[57.784] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU
at PCI:1:0:0.  Please
[57.784] (EE) NVIDIA(GPU-0): check your system's kernel log
for additional error
[57.784] (EE) NVIDIA(GPU-0): messages and refer to Chapter 8:
Common Problems in the
[57.784] (EE) NVIDIA(GPU-0): README for additional information.
[57.784] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA
graphics device!

I suggest trying out upstream's suggestions in [1], i.e. adding
"rcutree.rcu_idle_gp_delay=1" to your grub command line and/or using a
more up-to-date kernel from jessie-backports.

Regards,
Vincent

[1] https://github.com/Bumblebee-Project/Bumblebee/issues/615

Bug#820375: RM: libgstreamer-vaapi1.0-0, libgstreamer-vaapi1.0-dev -- ROM; obsolete

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: tjaal...@debian.org

The latest sid update to src:gstreamer-vaapi (1.8.0-1) drops binary
packages libgstreamer-vaapi1.0-0 and libgstreamer-vaapi1.0-dev, both
of which are obsolete and have no reverse deps/build-deps. Please
remove these packages.

Regards,
Vincent

Bug#785897: your mail

[Vincent Cheng]

Hi Moritz,

On Fri, Jan 29, 2016 at 10:46 AM, Moritz Mühlenhoff <j...@inutil.org> wrote:
> On Fri, May 22, 2015 at 07:47:50PM -0700, Vincent Cheng wrote:
>> forwarded 785897 https://github.com/exaile/exaile/issues/3
>
> Hi Vincent,
> there's now only a handful of packages left depending on gstreamer 0.10.
>
> The port of exaile doesn't yet seem to be in a usable state? I'd
> say let's remove exaile from the archive for now and reintroduce
> it once upstream is done porting it to gstreamer 1.0?

Ack, please feel free to file a RM bug for exaile.

Regards,
Vincent

Bug#809546: conky-std: conky is compiled without BUILD_MATH (-cli,-std,-all)

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Andrei,

On Thu, Dec 31, 2015 at 7:08 PM, Andrei Paskevich  wrote:
> Package: conky-std
> Version: 1.10.1-2
> Severity: normal
>
> Dear Maintainer,
>
> first of all, happy New Year!
>
> I found that the gauge indicators are broken (gauge line missing)
> and the -l option (logarithmic scale) is ignored in the graphs.
> According to the man page, this is caused by conky being compiled
> without BUILD_MATH. Indeed, it seems that the corresponding option
> is never used in debian/rules. I think, "-DBUILD_MATH=ON" should be
> added to COMMON_CONF_ARGS (or at least to the -std and -all rules).

cmake/ConkyBuildOptions.cmake defaults to BUILD_MATH being set to
on/true by default, and if you take a look at the output of "conky
-V", you should already see "math" listed under "General" compiled-in
features. This sounds like an upstream bug, so please file a bug
report upstream at [1] unless you still think it's Debian-specific
somehow?

Happy New Year!

Regards,
Vincent

[1] https://github.com/brndnmtthws/conky/issues/new

Bug#809541: devscripts: [uscan] please provide a quiet/no-verbose option

[Vincent Cheng]

Package: devscripts
Version: 2.15.10
Severity: wishlist

Dear Maintainer,

Please consider providing an option to suppress uscan output, specifically to
emulate the behaviour of "uscan --report" in previous versions of devscripts
(<= 2.15.9), where only errors or new upstream releases get printed out to
console.

Regards,
Vincent

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID="AA1F32FF"
DEBUILD_LINTIAN=no

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3-3-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.3
ii  libc62.21-6
ii  perl 5.20.2-6
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.1.5
ii  at  3.1.18-2
ii  curl7.45.0-1+b1
ii  dctrl-tools 2.24-1
ii  debian-keyring  2015.11.30
ii  dput0.9.6.4
ii  dupload 2.7.0
ii  equivs  2.0.9+nmu1
ii  fakeroot1.20.2-1
ii  file1:5.25-2
ii  gnupg   1.4.20-1
ii  gnupg2  2.0.28-3
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.19-1
ii  liburi-perl 1.69-1
ii  libwww-perl 6.15-1
ii  lintian 2.5.39.1
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.25-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-20
ii  wdiff   1.2.2-1+b1
ii  wget1.17.1-1
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  build-essential  11.7
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
ii  gnuplot  4.6.6-3
ii  gpgv 1.4.20-1
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.5.24-1
ii  openssh-client [ssh-client]  1:7.1p1-5
ii  s-nail [mailx]   14.8.5-4
ii  svn-buildpackage 0.8.5+nmu1
ii  w3m  0.5.3-26

-- no debconf information

Bug#809373: RM: wesnoth-1.13 -- ROM; to be maintained in experimental instead

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: rho...@debian.org

Please remove wesnoth-1.13 from unstable. This package is not suitable
for release, since it's the development branch of wesnoth;
wesnoth-1.12 is the current stable branch that is suitable to be
included in a stable release. We intend to maintain development
branches of wesnoth in experimental only from now on. Thanks!

(rhonda, if you have any additional rationale to add, please feel free to do so)

Regards,
Vincent

Bug#793863: Add new package f2fs-tools-dev for external development use

[Vincent Cheng]

Hi Kai-Chung,

On Mon, Dec 21, 2015 at 7:12 AM, 殷啟聰  wrote:
> Hi Vincent,
>
> Since you became silent again..., several days ago we submitted the
> patch to upstream, but they are also really sloow in accepting
> it... Maybe you can do it before the upstream does? Thank you!

Upstream released f2fs-tools 1.6.0 with your change today and I've
just uploaded the package to NEW. Sorry for the lengthy delay...

Happy holidays,
Vincent

Bug#808716: supertuxkart: FTBFS on armhf

[Vincent Cheng]

Package: supertuxkart
Version: 0.9.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

supertuxkart/0.9.1-1 FTBFS only on armhf; full build log at [1], tail
of build log as follows:

lib/angelscript/projects/cmake/libangelscript.a(as_callfunc.cpp.o): In
function `CallSystemFunction(int, asCContext*)':
/«PKGBUILDDIR»/lib/angelscript/source/as_callfunc.cpp:680: undefined
reference to `CallSystemFunctionNative(asCContext*,
asCScriptFunction*, void*, unsigned long*, void*, unsigned long long&,
void*)'
collect2: error: ld returned 1 exit status

Help would be appreciated!

Regards,
Vincent

[1] 
https://buildd.debian.org/status/fetch.php?pkg=supertuxkart=armhf=0.9.1-1=1450754030

Bug#804241: Please update initramfs in postinst (maybe)

[Vincent Cheng]

Hi Steve,

On Fri, Nov 6, 2015 at 5:54 AM, Steve McIntyre  wrote:
> Source: f2fs-tools
> Version: 1.4.1-1
> Severity: important
> Tags: d-i
>
> Hi!
>
> Since the move to systemd as the default init system, the initramfs
> will attempt to fsck and mount both / and /usr (where applicable). To
> aid this, initramfs-tools will copy necessary filesystem tools into
> the initramfs when it is generated.
>
> To make this work well, all filesystem tools packages for filesystems
> that are likely to be used for / and/or /usr should call
> "update-initramfs -u" in their postinst. This will
>
>  (a) ensure that necesssary fsck tools are included in the initramfs
>  generated by debian-installer (see #801961 for an example failure
>  here); and
>  (b) ensure that bug fixes to fsck tools get included immediately in
>  the initramfs
>
> I've checked your package and I don't see any update-initramfs
> calls. Please add one, if you consider f2fs to be a likely/sensible
> option as a base (/ or /usr) filesystem. If you'd like help doing that
> postinst work, I can supply a patch - just ask!

Yep, this sounds like a valid use case (e.g. my Raspberry Pi uses a
f2fs-formatted root filesystem).

All that's needed here is an unconditional call to "update-initramfs
-u" on postinst and postrm, right? Just to make sure I get this right,
would you be able to point me to another package that does the right
thing here (or even a patch if you have time)? Thanks!

Regards,
Vincent

Bug#793863: Add new package f2fs-tools-dev for external development use

[Vincent Cheng]

Hi Kai-Chung,

On Thu, Nov 12, 2015 at 6:38 AM, 殷啟聰  wrote:
> Hi Vincent,
>
> Sorry for the late reply. I have fixed the FTBFS and it's buildable
> now. Please check the patch attached or visit
> .
> Here is the changes:
>
>   * FTBFS because I installed the binaries to /usr/sbin(lib) rather
> than /sbin(lib). Actually I did it by mistake. :(
>   * Merged all library packages into f2fs-libs and f2fs-libs-dev
>   * No longer specify version info in soname
>
> Note that using *.install files and dh-exec makes multi-package more
> manageable. It seems quite complicated and tedious to use dh_install
> in debian/rules for installing multiple packages. dh-exec method is
> also documented and recommended by Debian wikis
> .
>
> Thank you for reviewing the patch, I hope the package can be ready
> soon because Android SDK packages needs this.

Sorry for the repeated delays; I'm currently quite busy with school
nowadays, but I'll try to upload an updated f2fs-tools to the archive
sometime this weekend. I took a quick look at your patch and it looks
good, although I'm still not convinced dh-exec actually simplifies
things; aren't the files already placed in the right directories if
you just pass --libdir=/lib/$(DEB_HOST_MULTIARCH)?

Would you be interested in co-maintaining f2fs-tools, by the way
(assuming you already have access to collab-maint, feel free to add
yourself to uploaders)? In addition to your bug, I want to fix #804241
before uploading, and there's also a new upstream release to be
packaged. If you have some spare time on your hands I'd be glad for
any help. :)

Regards,
Vincent

Bug#803744: f2fs-tools: use of f2fs as rootfs is broken

[Vincent Cheng]

Hi Sven,

On Mon, Nov 2, 2015 at 12:38 AM, Sven Geggus
 wrote:
> Source: f2fs-tools
> Severity: normal
>
> Hello,
>
> at least when using System-V Init Debian is currently not able to run from
> a f2fs root. The reason is, that fsck.f2fs is unable to check a ro mounted fs.
>
> As this is also the case with xfs there is an easy solution:
>
> 1. Rename fsck.f2fs to something else like f2fs_repair or f2fs_check.
>
> 2. Copy fsck.xfs script to fsck.f2fs or replace with a slightly modified 
> Version
>   (e.g. printing F2FS instead of xfs).

I have no problems running Debian with a f2fs root (on a Raspberry Pi,
to be precise).

If this is a question of fsck.f2fs not supporting the same options as
other fsck implementations, IMHO that should be fixed upstream instead
of adding a workaround in Debian with a wrapper script.

Regards,
Vincent

Bug#800747: wesnoth-1.12: Some buttons don't respond to mouse clicks

[Vincent Cheng]

Control: tags -1 + moreinfo unreproducible

Hi Ben,

On Sat, Oct 3, 2015 at 12:45 AM, Ben Longbons  wrote:
> Package: wesnoth-1.12
> Version: 1:1.12.4-1
> Severity: important
>
> Dear Maintainer,
>
> A handful of the UI buttons cannot be clicked (tested with multiple mice).
>
> In particular I have noted:
>
> * The "End Turn / End Scenario" button (action menu or ctrl-space works)
> * The "OK" button in the Addons Manager (double-click or enter works)
> * The "Close" button in Help/Unit Description (escape works)
>
> This did not occur with wesnoth-1.10.
>
> Using the keyboard shortcuts or alternative mouse actions above still works,
> and the mouse works perfectly on all other buttons that I have noticed.
>
> (I normally use the keyboard, but was demoing the game for a friend, so
> this was quite embarrassing.)
>
> There is also something funny with clicking on a unit that has
> had the spacebar pressed to ignore its remaining move for the N key. It
> cannot be moved unless you press space again and *then* press the N key.

Unfortunately I cannot reproduce this at all; UI buttons work as
expected for me.

I have no idea what might be causing this issue; you may want to
report this directly upstream and see if they have any suggestions.
Instructions for filing a bug report for wesnoth can be found at [1].

Regards,
Vincent

[1] http://wiki.wesnoth.org/Reportingbugs

Bug#799725: Please remove alternate build deps for gstreamer 0.10

[Vincent Cheng]

On Mon, Sep 21, 2015 at 1:31 PM, Moritz Muehlenhoff  wrote:
> Source: kivy
> Severity: normal
>
> Hi,
> kivy is using gstreamer 1.0, but still has alternate build-deps/deps
> on gstreamer 0.10:
>
> libgstreamer0.10-dev
> python-gst0.10
>
> Please remove these, gstreamer 0.10 is scheduled for removal from
> the archive.

Is it not possible to keep these alternate build-deps in d/control to
e.g. ease backporting? My understanding is that the dependency
resolver that buildds use will only look at the first build-dep and
disregard alternate build-deps.

Regards,
Vincent

Bug#798694: irrlicht: broken with gcc-5

[Vincent Cheng]

Package: src:irrlicht
Version: 1.8.2+dfsg1-1
Severity: serious

Latest irrlicht release breaks minetest, and is a known issue upstream
[1] (and a new upstream release is due to come out soon to fix this);
let's block irrlicht from migrating to testing for now.

Regards,
Vincent

[1] http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7=50952

Bug#797895: libvdpau: CVE-2015-5198, CVE-2015-5199, CVE-2015-5200

[Vincent Cheng]

On Sat, Sep 5, 2015 at 7:00 AM, Luca Boccassi <luca.bocca...@gmail.com> wrote:
> On Thu, 2015-09-03 at 22:40 -0700, Vincent Cheng wrote:
>> On Thu, Sep 3, 2015 at 5:24 PM, Luca Boccassi <luca.bocca...@gmail.com> 
>> wrote:
>> > On Thu, 2015-09-03 at 14:49 +0200, Alessandro Ghedini wrote:
>> >> Source: libvdpau
>> >> Severity: important
>> >> Tags: security, fixed-upstream
>> >>
>> >> Hi,
>> >>
>> >> the following vulnerabilities were published for libvdpau.
>> >>
>> >> CVE-2015-5198[0]:
>> >> incorrect check for security transition
>> >>
>> >> CVE-2015-5199[1]:
>> >> directory traversal in dlopen
>> >>
>> >> CVE-2015-5200[2]:
>> >> vulnerability in trace functionality
>> >>
>> >> All of them are fixed by the patch [3], shipped in the 1.1.1 upstream
>> >> release.
>> >>
>> >> If you fix the vulnerabilities please also make sure to include the
>> >> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>> >
>> > Hello Alessandro,
>> >
>> > Thanks for the heads-up!
>> >
>> > Vincent, Andreas,
>> >
>> > I have updated the libvdpau git repo with the new release [1]. I have
>> > tested the amd64 and i386 packages in Jessie, and they seem to work just
>> > fine with vdpauinfo and VLC.
>> >
>> > Could you please review and do a new upload, when you have time?
>> >
>> > Thanks!
>> >
>> > Tomorrow I'll look into backporting the fix to Wheezy and Squeeze.
>>
>> Uploaded, thanks! I'll make a note to myself to update the package in
>> jessie-backports as well. Luca, let me know if you need a sponsor for
>> the wheezy-pu/jessie-pu or wheezy-security/jessie-security uploads (I
>> don't know if these CVEs warrant a DSA, so ping the security team
>> first with a source debdiff and see what they say, and if they say no
>> then ping the release team instead); thanks for taking care of updates
>> for stable/oldstable/oldoldstable!
>
> Hello Vincent,
>
> Thanks for uploading 1.1.1!
>
> I have pushed to the git repo the backported changes for jessie [1] and
> wheezy [2]. Alessandro confirmed that the Security Team would like to
> release a DSA for this [3], so could you please sponsor the upload to
> security-master when you have time? I added you to the Uploaders in the
> wheezy branch already.

Uploaded to security-master, thanks for preparing these updated
packages! It's worth pointing out that adding yourself to uploaders in
d/control isn't necessary for security uploads, although I suppose it
doesn't actually make any difference either way.

I'll take a look at the squeeze-lts update next.

Regards,
Vincent

Bug#794852: codeblocks: non DFSG file in the source package

[Vincent Cheng]

Pinging this bug to delay autoremoval from testing; codeblocks is
already fixed in unstable, but testing migration is delayed due to
gcc-5 transition.

Regards,
Vincent

Bug#741573: [CTTE #741573] Debian Menu System

[Vincent Cheng]

(Please keep me cc-ed, I'm not subscribed to debian-ctte.)

Hi,

On Thu, Sep 3, 2015 at 8:34 PM, Don Armstrong  wrote:
>2. In addition to those changes, the Technical Committee resolves
>   that packages providing a .desktop file shall not also provide a
>   menu file for the same application.

Does this mean that packages providing both a .desktop and a Debian
menu file are immediately RC-buggy as of now (i.e. is "shall not"
equivalent to "must not" or "should not" in Policy-speak)?

Regards,
Vincent

Bug#797974: both .desktop and .menu file shipped

[Vincent Cheng]

Hi,

On Thu, Sep 3, 2015 at 10:15 PM, chrysn  wrote:
> Package: hyperrogue
> Version: 4.2+dfsg-1+b1
> Severity: minor
>
> As per CTTE #741573, "packages providing a .desktop file shall not also
> provide a menu file", which hyperrogue does; it should drop the .menu file.

The recent CTTE decision sounds like it'll involve a mass bug filing
to fix all affected packages. Please do not file bugs piecemeal;
follow the instructions in devref 7.1.1 [1] instead and consider
creating a patch for lintian to implement the CTTE decision.

Regards,
Vincent

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#submit-many-bugs