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#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#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#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#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#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#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#868049: [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#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#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#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#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#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#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#812680: marked as pending

[Vincent Cheng]

tag 812680 pending
thanks

Hello,

Bug #812680 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=python-modules/packages/python-poppler.git;a=commitdiff;h=cb95dbe

---
commit cb95dbe84e01d69d33c25e0a6167b53b947ced78
Author: Vincent Cheng <vch...@debian.org>
Date:   Sat May 28 22:39:32 2016 -0700

fix poppler 0.39 ftbfs

diff --git a/debian/changelog b/debian/changelog
index 7088197..c705686 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ python-poppler (0.12.1-9) UNRELEASED; urgency=low
   * Acknowledge NMU. Thanks Gregor!
 
   [ Vincent Cheng ]
+  * Fix FTBFS with poppler 0.39. (Closes: #812680)
   * Add dh-python to build-depends.
   * Bump standards version to 3.9.8 (no changes needed).
 

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#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#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#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#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#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#795065: dbus-c++: library transition needed for g++-5

[Vincent Cheng]

user release.debian@packages.debian.org
usertag 795065 + transition
severity 795065 normal
block 795065 by 790756
reassign 795065 release.debian.org
thanks

Hi Simon,

On Tue, Aug 18, 2015 at 1:11 AM, Simon McVittie s...@debian.org wrote:
 Control: tags 795065 + patch

 On Mon, 10 Aug 2015 at 08:41:54 +0100, Simon McVittie wrote:
 In the case of dbus-c++, it seems that std::string is part of the ABI.
 https://buildd.debian.org/status/package.php?p=libffado says libffado
 failed to build from source

 I have uploaded the necessary gtkmm2.4 version to unblock this, which is
 now in the binary NEW queue. I intend to NMU dbus-c++ with the attached patch
 after gtkmm2.4 reaches unstable, assuming I do not find any obvious
 errors in test rebuilds of the reverse dependencies ffado and sflphone.

Thanks for the patch! It looks like your gtkmm2.4 upload has already
made it through NEW, so I've gone ahead and uploaded dbus-c++ myself.

Regards,
Vincent

Bug#787698: supertux: FTBFS on big-endian archs

[Vincent Cheng]

Hi Fabian,

On Mon, Aug 17, 2015 at 4:06 AM, Fabian Greffrath fab...@greffrath.com wrote:
 Control: tags -1 + patch

 Am Montag, den 08.06.2015, 09:07 +0200 schrieb Fabian Greffrath:
   *((char *)buffer) = tmp;

 Correction: You'll also need to dereference the tmp pointer, i.e.:

 --- supertux-0.3.5a.orig/src/audio/wav_sound_file.cpp
 +++ supertux-0.3.5a/src/audio/wav_sound_file.cpp
 @@ -159,7 +159,7 @@ WavSoundFile::read(void* buffer, size_t
  tmp[2*i+1] = c;
}

 -  *buffer = tmp;
 +  *(char *)buffer = *tmp;
  #endif

return readsize;


Thanks for the patch, and sorry for dropping the ball on this! I'll
upload an updated package within the next hour.

Regards,
Vincent

Bug#787698: supertux: FTBFS on big-endian archs

[Vincent Cheng]

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

supertux/0.3.5a-1 currently FTBFS on mips, powerpc, s390x, and sparc. Build
logs can be found at [1]; tail of build log is as follows:

[ 89%] Building CXX object 
CMakeFiles/supertux2.dir/src/audio/wav_sound_file.cpp.o
/usr/bin/c++-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2  -std=c++11 -I/usr/include/GL 
-I/usr/include/AL -I/«PKGBUILDDIR»/obj-mips-linux-gnu -I/«PKGBUILDDIR»/src 
-I/«PKGBUILDDIR»/external/squirrel/include 
-I/«PKGBUILDDIR»/external/tinygettext/include 
-I/«PKGBUILDDIR»/external/findlocale -I/«PKGBUILDDIR»/external/obstack -isystem 
/usr/include/SDL2-Wall -Wextra -Wno-unused-parameter -funit-at-a-time 
-fno-strict-aliasing -o CMakeFiles/supertux2.dir/src/audio/wav_sound_file.cpp.o 
-c /«PKGBUILDDIR»/src/audio/wav_sound_file.cpp
/«PKGBUILDDIR»/src/audio/wav_sound_file.cpp: In member function 'virtual size_t 
WavSoundFile::read(void*, size_t)':
/«PKGBUILDDIR»/src/audio/wav_sound_file.cpp:162:4: error: 'void*' is not a 
pointer-to-object type
   *buffer = tmp;
^
make[3]: *** [CMakeFiles/supertux2.dir/src/audio/wav_sound_file.cpp.o] Error 1

Any help (or better yet, patches) would be greatly appreciated!

Regards,
Vincent

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

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

Kernel: Linux 4.0-4-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 supertux depends on:
ii  libc6 2.19-18
ii  libcurl3-gnutls   7.42.1-2
ii  libgcc1   1:5.1.1-8
ii  libgl1-mesa-glx [libgl1]  10.5.5-1
ii  libglew1.10   1.10.0-3
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libogg0   1.3.2-1
ii  libopenal11:1.16.0-3
ii  libphysfs12.0.3-2
ii  libsdl2-2.0-0 2.0.2+dfsg1-7
ii  libsdl2-image-2.0-0   2.0.0+dfsg-3+b4
ii  libstdc++65.1.1-8
ii  libvorbis0a   1.3.4-2
ii  libvorbisfile31.3.4-2
ii  supertux-data 0.3.5a-1

supertux recommends no packages.

supertux suggests no packages.

-- no debconf information


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

Bug#744115: codeblocks: diff for NMU version 13.12-3.1

[Vincent Cheng]

Hi Olly,

On Wed, May 13, 2015 at 5:55 PM, Olly Betts o...@survex.com wrote:
 It's high time we actually got rid of wxwidgets2.8, so I took another
 look at this bug.

 Upstream have yet to make a release from trunk, so I tried to make
 minimal changes to get 13.12 working rather than packaging a VCS
 snapshot.

 Olly Betts wrote:
 On Thu, Apr 10, 2014 at 04:59:25AM -0700, Vincent Cheng wrote:
  My understanding is that upstream is working towards porting
  codeblocks for wx 3.0, but it's currently not fully stable yet (e.g.
  #736368).

 The issue there is most likely because wx 3.0 enables WXDEBUG mode
 by default which includes checks for incorrect API usage, whereas with
 wx 2.8 you had to specify it explicitly when you built the library.  In
 other words, codeblocks is misusing the wx API, but with 2.8 this gets
 quietly ignored by default, whereas 3.0 reports it by default.

 I bet if you rebuilt codeblocks using the WXDEBUG build of 2.8
 (available in Debian in package libwxgtk2.8-dbg - despite the name, this
 isn't debug symbols, but a separate build of the library) you'd see this
 assertion too.

 The simplest way to address this is to build codeblocks with -DNDEBUG
 (pass it in CPPFLAGS usually), which makes wx 3.0 behave as a default
 build of 2.8 would.

 I tested this workaround and I can't reproduce #736368 in a build with
 -DNDEBUG defined.  It's a shame we didn't actually test that before
 jessie - sorry about that.

 Running cleanly without disabling the WXDEBUG checks would be better,
 but these checks are off by default in wx2.8, so it's no worse than the
 current situation, and it doesn't seem worth investing time trying to
 track down the relevant fixes from trunk.

Ack; sorry on my side for dropping the ball on this.

 Vincent Cheng vch...@debian.org writes:
 In case I haven't made it clear previously, you're more than welcome
 to NMU codeblocks; I doubt David and/or Michael would object.

 Thanks, I've prepared an NMU for codeblocks (versioned as 13.12-3.1) and
 uploaded it.

Thanks, I've committed your changes to collab-maint as well.

Regards,
Vincent


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

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

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible
Control: severity -1 important

Hi,

On Sun, Mar 29, 2015 at 11:48 PM, Pirate Praveen prav...@debian.org wrote:
 package: gnote
 version: 3.14.2-1
 severity: grave
 reason: gnote is unusable with this

 When I manually created this file, I could start gnote and use it normally.

 I had just installed it and using it for the first time.

 pravi@savannah:~/forge/diaspora$ gnote
 Segmentation fault (core dumped)
 pravi@savannah:~/forge/diaspora$ gdb gnote
 GNU gdb (Debian 7.7.1-2) 7.7.1
 Copyright (C) 2014 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-linux-gnu.
 Type show configuration for configuration details.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/.
 Find the GDB manual and other documentation resources online at:
 http://www.gnu.org/software/gdb/documentation/.
 For help, type help.
 Type apropos word to search for commands related to word...
 Reading symbols from gnote...(no debugging symbols found)...done.
 (gdb) run
 Starting program: /usr/bin/gnote
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
 [New Thread 0x7fffea870700 (LWP 5454)]
 [New Thread 0x7fffe9e62700 (LWP 5455)]

 (gnote:5450): glibmm-CRITICAL **:
 unhandled exception (type Glib::Error) in signal handler:
 domain: g-io-error-quark
 code  : 1
 what  : Error opening file
 '/home/pravi/.local/share/gnote/33c7ece0-72fa-4c6a-b27f-84cf78f04e84.note':
 No such file or directory

 [New Thread 0x7fffe9661700 (LWP 5456)]
 [Thread 0x7fffea870700 (LWP 5454) exited]
 [Thread 0x7fffe9e62700 (LWP 5455) exited]
 [Thread 0x77fa9a00 (LWP 5450) exited]
 [Inferior 1 (process 5450) exited with code 01]
 (gdb)


I can't reproduce that segfault myself, even after removing
~/.local/share/gnote (to simulate running gnote for the first time).

I'm about to upload gnote 3.16 to sid; please check to see if it's
still reproducible with the latest upstream release. If so, can you
please file a bug report upstream at [1]? Thanks!

Regards,
Vincent

[1] http://bugzilla.gnome.org/enter_bug.cgi?product=gnote


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

Bug#773191: python-ogg-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Vincent Cheng]

Hi Sandro,

On Sun, 21 Dec 2014 10:50:15 + Sandro Tosi mo...@debian.org wrote:
 Hi Jean-Michel,
 Thanks for your work, I will fix the package soon from dpmt repo; and yes
 the right solution is to use dpkg maint scripts to fix the dir-link
 transition.

Any update on this? pyogg is showing up on the release team's list of
packages to be autoremoved soon [1][2], along with all its
reverse-deps, so if you'd like a helping hand, I'd be glad to NMU
this.

Regards,
Vincent

[1] http://nthykier.wordpress.com/2014/12/30/status-on-jessie-december-2014/
[2] 
https://udd.debian.org/bugs/?release=jessiemerged=ignkeypackages=ignfnewerval=7flastmodval=7rc=1chints=1cdeferred=1crttags=1sortby=idsorto=ascformat=html#results


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

Bug#773036: libetpan-dbg: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Vincent Cheng]

Hi Ricardo,

I've attached a full debdiff (in the form of a NMU), which I haven't
uploaded yet (but I'm happy to upload this if you have no objections).
As for how to test it, well, I'm not an expert when it comes to
piuparts, but I was able to reproduce the original error with:

# piuparts -m 'http://ftp.debian.org/debian/' -a -d wheezy -d sid libetpan-dbg

After applying the attached debdiff and building libetpan, you can use
the following pbuilder invocation to check your package (I guess you
can ignore the debsums-related error that piuparts spits out):

# piuparts -m 'http://ftp.debian.org/debian/' -d wheezy -d sid
libetpan_1.5-1.1_amd64.changes

Regards,
Vincent


libetpan_1.5-1.1.debdiff
Description: Binary data

Bug#733496: Code copy of older Mozilla code

[Vincent Cheng]

On Sat, Dec 6, 2014 at 4:57 AM, Moritz Mühlenhoff j...@inutil.org wrote:
 severity serious
 thanks

 This package forks a local copy of the Iceweasel Javascript engine which is
 no longer supported with security updates (currently only the ESR24 series
 is maintained)

 What's the strategy here? Do you plan to backport/triage all Javascript 
 related
 security issues from current Mozilla releases to your version?

 Why do we need a copy of the old version anyway? What are the expected 
 applications
 using it and why can't they be migrated to the mozjs provided by the 
 iceweasel
 source package.

 There are no reverse dependencies left for mozjs17, so we should remove it 
 now:
 (mozjs and mozjs24 can be kept, but they aren't covered by security support)

RM bug filed as #772442.

Regards,
Vincent


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

Bug#741834: [Python-modules-team] Bug#741834: patch to add LC_ALL=C

[Vincent Cheng]

Control: tag -1 + pending

On Mon, Nov 10, 2014 at 1:46 PM, Thomas Viehmann t...@beamnet.de wrote:
 tag 741834 +patch
 thank you

 Hi,

 this is a tiny patch to address the test failures.

Thanks for the patch Thomas! Will upload soon.

Regards,
Vincent


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

Bug#768206: love-doc: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/doc/love/demos/lovalanche.love

[Vincent Cheng]

Control: tag -1 + pending

On Mon, Nov 10, 2014 at 8:51 AM, Juhani Numminen
juhaninummin...@gmail.com wrote:
 Control: tags -1 + patch

 Hi,

 This seems to be caused by moving files between packages without adding
 the needed Breaks and Replaces. I made a patch (svn diff) for the
 package with the help of Debian wiki page[1].

Thanks for the patch! Will upload soon. (Note that it's unnecessary
for love to declare a breaks relation against love-doc.)

Regards,
Vincent


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

Bug#766821: HELP: Bug#766821: relion: FTBFS: B-D on nonexistent openmpi-gcc

[Vincent Cheng]

Hi Andreas,

On Sat, Oct 25, 2014 at 11:24 PM, Andreas Tille andr...@an3as.eu wrote:
 Hi Aaron,

 On Sat, Oct 25, 2014 at 11:47:32PM -0400, Aaron M. Ucko wrote:
 Source: relion
 Version: 1.3+dfsg-1
 Severity: serious
 Justification: fails to build from source

 Automatic builds of relion have been failing because it declares a
 build dependency on the nonexistent openmpi-gcc package.  Yes, it
 lists libopenmpi-dev as an alternative; however, for the sake of
 better reproducibility, Debian's autobuilders are configured to
 consider alternatives only when forced to by explicit architecture
 restrictions on otherwise preferred choices.

 Could you please take a look?

 Anny suggestion for a solution since I have no idea about those
 other architectures?

Drop the build-dep on openmpi-gcc.

You must make sure that the first build dependency in a set of
alternative build-deps is always installable, otherwise it's going to
FTBFS on the buildds (even if it builds fine for you locally). This
isn't an arch-specific problem if that's what you're concerned about;
if you had uploaded source+i386 (instead of amd64) packages, the amd64
build would have failed on the buildds instead.

Regards,
Vincent


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

Bug#766821: HELP: Bug#766821: relion: FTBFS: B-D on nonexistent openmpi-gcc

[Vincent Cheng]

On Sun, Oct 26, 2014 at 12:40 AM, Paul Gevers elb...@debian.org wrote:
 On 26-10-14 07:37, Vincent Cheng wrote:
 Anny suggestion for a solution since I have no idea about those
 other architectures?

 Drop the build-dep on openmpi-gcc.

 You must make sure that the first build dependency in a set of
 alternative build-deps is always installable, otherwise it's going to
 FTBFS on the buildds (even if it builds fine for you locally). This
 isn't an arch-specific problem if that's what you're concerned about;
 if you had uploaded source+i386 (instead of amd64) packages, the amd64
 build would have failed on the buildds instead.

 Or, if you want openmpi-gcc to be used on the architectures where it is
 available, use the arch syntax in the BD.

 e.g. (untested)
 Build-Depends: openmpi-gcc (amd64), libopenmpi-dev (!amd64)

Err, I'm pretty sure the syntax for arch-specific build-deps uses
brackets, not parentheses, i.e. openmpi-gcc [amd64] | libopenmpi-dev
[!amd64]. Also, openmpi-gcc isn't installable in sid on any arch,
including amd64.

Regards,
Vincent


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

Bug#766011: racket-common: trying to overwrite '/usr/share/doc/racket/release/stamp.sxref'

[Vincent Cheng]

Package: racket-common
Version: 6.1-1
Severity: serious
Justification: Policy 7.6.1

Unpacking racket (6.1-1) over (5.3.6+dfsg1-1) ...
Preparing to unpack .../racket-common_6.1-1_all.deb ...
Unpacking racket-common (6.1-1) over (5.3.6+dfsg1-1) ...
dpkg: error processing archive
/var/cache/apt/archives/racket-common_6.1-1_all.deb (--unpack):
 trying to overwrite '/usr/share/doc/racket/release/stamp.sxref', which is also
 in package racket-doc 5.3.6+dfsg1-1
 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


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

Kernel: Linux 3.16-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

Versions of packages racket depends on:
ii  libc6  2.19-11
ii  libffi63.1-2
ii  racket-common  5.3.6+dfsg1-1

Versions of packages racket recommends:
iu  racket-doc  6.1-1

racket suggests no packages.

-- no debconf information


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

Bug#762551: RFS: Re: Bug#762551: jumpnbump-levels: Package has no uploaders

[Vincent Cheng]

On Mon, Sep 29, 2014 at 3:18 AM, Fabian Greffrath fab...@greffrath.com wrote:
 Hi all,

 Am Dienstag, den 23.09.2014, 00:53 -0700 schrieb Vincent Cheng:
 jumpnbump-levels does not currently have any human uploaders. This is a
 violation of a must directive in Policy 5.6.3 [1], hence it is a RC bug.

 I have prepared a new package in

 http://anonscm.debian.org/cgit/pkg-games/jumpnbump-levels.git/

 in which I have also added myself to Uploaders.

 Please upload this package, thanks!

It looks like tobi already uploaded this. Sorry for not responding
sooner (last week was really busy for me).

Regards,
Vincent


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

Bug#762551: jumpnbump-levels: Package has no uploaders

[Vincent Cheng]

Source: jumpnbump-levels
Version: 20091107
Severity: serious
Justification: Policy 5.6.3

Dear Maintainer,

jumpnbump-levels does not currently have any human uploaders. This is a
violation of a must directive in Policy 5.6.3 [1], hence it is a RC bug.

Regards,
Vincent

[1] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlfieldslist


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

Bug#762186: python-pypdf: Unexpectedly breaks existing programs on update

[Vincent Cheng]

Dear maintainer,

On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi
valhall...@trueelena.org wrote:
 Package: python-pypdf
 Version: 1.23-1
 Severity: grave
 Justification: renders package unusable

 Dear Maintainer,

 updating python-pypdf from 1.13 to 1.23 breaks every existing script
 that use this module with an ImportError: No module named pyPdf.

 Changing pyPdf to PyPDF2 everywhere in the scripts allows to use
 the new version, but in the update there was no hint that this
 change was needed.

 Expecially if this happens during an update between stable versions
 this will break existing deployments of custom programs, causing
 lots of pain.

Worse still is the fact that currently in sid, both src:python-pypdf
and src:pypdf2 build binary package python-pypdf. One of the above
source packages must stop building python-pypdf, and since pypdf2 is
the one that's breaking reverse dependencies, I would very much
appreciate it this is initially done in src:pypdf2.

The next time you package a fork as a new source package, please don't
immediately hijack the other package's namespace, and give a heads up
to maintainers of your library's reverse deps so that they have time
to react. It'd be really nice if you could also coordinate an informal
transition and offer patches/NMUs to fix up pypdf's reverse
dependencies.

Regards,
Vincent


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

Bug#762186: [Python-modules-team] Bug#762186: python-pypdf: Unexpectedly breaks existing programs on update

[Vincent Cheng]

On Sun, Sep 21, 2014 at 2:54 AM, Vincent Cheng vch...@debian.org wrote:
 Dear maintainer,

 On Thu, 18 Sep 2014 22:42:50 +0200 Elena Grandi
 valhall...@trueelena.org wrote:
 Package: python-pypdf
 Version: 1.23-1
 Severity: grave
 Justification: renders package unusable

 Dear Maintainer,

 updating python-pypdf from 1.13 to 1.23 breaks every existing script
 that use this module with an ImportError: No module named pyPdf.

 Changing pyPdf to PyPDF2 everywhere in the scripts allows to use
 the new version, but in the update there was no hint that this
 change was needed.

 Expecially if this happens during an update between stable versions
 this will break existing deployments of custom programs, causing
 lots of pain.

 Worse still is the fact that currently in sid, both src:python-pypdf
 and src:pypdf2 build binary package python-pypdf. One of the above
 source packages must stop building python-pypdf, and since pypdf2 is
 the one that's breaking reverse dependencies, I would very much
 appreciate it this is initially done in src:pypdf2.

 The next time you package a fork as a new source package, please don't
 immediately hijack the other package's namespace, and give a heads up
 to maintainers of your library's reverse deps so that they have time
 to react. It'd be really nice if you could also coordinate an informal
 transition and offer patches/NMUs to fix up pypdf's reverse
 dependencies.


Looks like the BTS is a bit confused over who the maintainer for
src:pypdf2 is, so forwarding this directly to its maintainer.

Regards,
Vincent


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

Bug#762411: f2fs-tools: FTBFS on big-endian architectures

[Vincent Cheng]

Source: f2fs-tools
Version: 1.4.0-1
Severity: serious
Tags: help
Justification: fails to build from source (but built successfully in the past)

f2fs-tools 1.4.0 currently FTBFS on big-endian archs supported in Debian, i.e.
mips, powerpc, s390x, and sparc; tail of build log as follows:

/bin/bash ../libtool  --tag=CC   --mode=link gcc -Wall -DWITH_BLKDISCARD -g -O2
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o
mkfs.f2fs f2fs_format_main.o f2fs_format.o f2fs_format_utils.o -luuid
.../lib/libf2fs.la 
libtool: link: gcc -Wall -DWITH_BLKDISCARD -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -Wl,-z -Wl,relro -o .libs/mkfs.f2fs
f2fs_format_main.o f2fs_format.o f2fs_format_utils.o  -luuid
.../lib/.libs/libf2fs.so
f2fs_format.o: In function `f2fs_prepare_super_block':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:108: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:109: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:110: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:117: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:118: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:120: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:121: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:123: undefined reference to `bswap_32'
f2fs_format.o:/«PKGBUILDDIR»/mkfs/f2fs_format.c:124: more undefined references
to `bswap_32' follow
f2fs_format.o: In function `f2fs_prepare_super_block':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:133: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:151: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:156: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:159: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:163: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:165: undefined reference to `bswap_32'
f2fs_format.o:/«PKGBUILDDIR»/mkfs/f2fs_format.c:165: more undefined references
to `bswap_32' follow
f2fs_format.o: In function `f2fs_write_root_inode':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:710: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:711: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:711: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:716: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:717: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:718: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:719: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:721: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:722: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:723: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:725: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:727: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:729: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:734: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:737: undefined reference to `bswap_32'
f2fs_format.o:/«PKGBUILDDIR»/mkfs/f2fs_format.c:739: more undefined references
to `bswap_32' follow
f2fs_format.o: In function `f2fs_add_default_dentry_root':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:825: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:831: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:837: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:838: undefined reference to `bswap_32'
f2fs_format.o: In function `f2fs_write_check_point_pack':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:457: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:459: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:461: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:463: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:465: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:467: undefined reference to `bswap_32'
f2fs_format.o:/«PKGBUILDDIR»/mkfs/f2fs_format.c:469: more undefined references
to `bswap_32' follow
f2fs_format.o: In function `f2fs_write_check_point_pack':
/«PKGBUILDDIR»/mkfs/f2fs_format.c:475: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:476: undefined reference to `bswap_16'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:477: undefined reference to `bswap_64'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:478: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:479: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:479: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:479: undefined reference to `bswap_32'
/«PKGBUILDDIR»/mkfs/f2fs_format.c:483: undefined reference to `bswap_32'
f2fs_format.o:/«PKGBUILDDIR»/mkfs/f2fs_format.c:483: more undefined 

Bug#759851: missing libircclient.h error

[Vincent Cheng]

On Wed, Sep 17, 2014 at 1:08 AM, Robin Haeusler rhaeus...@bigpond.com wrote:
 I have tracked this bug report down, and it is still present as reported:

 In file included from src/RetroShareChat.cpp:5:0:
 src/IRC.h:10:39: fatal error: libircclient/libircclient.h: No such file
 or directory
  #include libircclient/libircclient.h
^
 compilation terminated.
 Makefile:97: recipe for target 'obj/Debug/src/RetroShareChat.o' failed
 make: *** [obj/Debug/src/RetroShareChat.o] Error 1
 make: *** Waiting for unfinished jobs

 I have updated my installation of Jessie, made sure installed (as
 reported by synaptic and apt-get), the documentation is installed but
 not the required *.h files in the library.

Make sure that this patch [1] is applied. If you fetch the Debian
source (e.g. using apt-get source pokerth / unpack using dpkg-source
-x pokerth*.dsc) and build using that, you should not be able to
reproduce this build failure. This FTBFS is no longer reproducible on
the buildds either [2].

Regards,
Vincent

[1] 
http://sources.debian.net/src/pokerth/1.1.1-2.1/debian/patches/10_fix_ftbfs_with_new_libircclient.patch/
[2] https://buildd.debian.org/status/package.php?p=pokerthsuite=unstable


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

Hi Olly,

On Tue, Sep 9, 2014 at 11:16 AM, Olly Betts o...@survex.com wrote:
 On Tue, Aug 26, 2014 at 03:55:19PM +1200, Olly Betts wrote:
 On Tue, Jul 01, 2014 at 02:33:51PM -0700, Vincent Cheng wrote:
  according to the forwarded bug report, it sounds like upstream is
  going to take a look at this.

 There's been no update on the upstream ticket for ages, so I've pinged
 it to see if they have made a decision on whether to make a new major
 release with wx3 compatibility.

 It's been 2 weeks and no response from upstream.  This is now one of 7
 packages remaining in the wxwidgets3.0 transition, and most of those have
 a fix in progress.  We really need to move things forwards if codeblocks
 is to make it into jessie.

 Maintainers - I think it's time to just make a call on this from the
 Debian side, unless you have connections with upstream which can get
 you an answer where I can't seem to.

Nope, I have no connections with upstream and have no idea what's
going on with the upstream wxwidgets3.0 port.

I've sort of neglected to take care of this package lately...which is
a bit ironic, given that the reason I added myself as an uploader in
the first place was because codeblocks was just bitrotting in the
archive at the time.

 Would you rather package a snapshot from the upstream VCS, or try to
 patch the currently packaged release for wx3?  We have a patch for the
 latter, but Vincent reported some issues with it (which I've not tried
 to reproduce myself, but I could take a look if you want to go that
 route).

In case I haven't made it clear previously, you're more than welcome
to NMU codeblocks; I doubt David and/or Michael would object. I'm open
to patching it if it's not too intrusive, otherwise I suggest just
dropping it for jessie and carrying on with the wxwidgets transition.
I don't think a package with maintainers that are more or less
inactive should be blocking it.

Regards,
Vincent


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

Bug#757648: Supertuxkart included non-free images.

[Vincent Cheng]

close 757648
thanks

On Sun, Sep 7, 2014 at 2:05 AM, Luke Faraone lfara...@debian.org wrote:
 On Sat, Aug 16, 2014 at 04:48:23PM -0700, Vincent Cheng wrote:
 Is the referenced file (installed as
 /usr/share/games/supertuxkart/data/gui/difficulty_best.png by
 supertuxkart-data) distributable or not? I'd like to have an
 authoritative answer before either closing this bug or pushing back on
 upstream (who don't agree with the bug reporter [1]).

 I'm not aware of a blanket policy on the utilisation of trademarked
 images in Debian. However, I do not believe this usage is problematic
 for Debian. If further clarification is required, questions should be
 directed to SPI's lawyers.

Ack, thanks for your input! Closing this bug report as a result.

(For the record, I agree with upstream's stance on this issue and
don't believe that copyright infringement has taken place here, but I
just wanted to check with ftpmasters for a second, more authoritative
opinion. Thanks again!)

Regards,
Vincent


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

Bug#757648: Supertuxkart included non-free images.

[Vincent Cheng]

Hi ftpmasters,

On Sat, Aug 16, 2014 at 4:48 PM, Vincent Cheng vch...@debian.org wrote:
 Hi ftpmasters,

 On Sun, Aug 10, 2014 at 1:51 AM, mejiko
 kame55-itasenpara...@y2.dion.ne.jp wrote:
 Package: supertuxkart
 Severity: serious

 Hello.

 Supertuxkart included non-free images. This is supertux images.

 supertux image used Superman logo.

 It is not distributable, Its non-free.


 File List:

 data/gui/diffculty_best.png

 [...]

 Reference:

 http://www.dccomics.com/copyright
 http://www.dccomics.com/terms-of-use
 https://bugzilla.redhat.com/show_bug.cgi?id=1128410
 https://trisquel.info/en/issues/12151

 Is the referenced file (installed as
 /usr/share/games/supertuxkart/data/gui/difficulty_best.png by
 supertuxkart-data) distributable or not? I'd like to have an
 authoritative answer before either closing this bug or pushing back on
 upstream (who don't agree with the bug reporter [1]).

 Regards,
 Vincent

 [1] https://github.com/supertuxkart/stk-code/issues/1446

Just a friendly ping regarding #757648 (and to delay autoremoval).

Regards,
Vincent


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

Bug#755513: Bug #755513 : nvidia-opencl-dev: binary conflict with ocl-icd-libopencl1

[Vincent Cheng]

On Mon, Sep 1, 2014 at 8:00 AM, Vincent Danjean vdanjean...@free.fr wrote:

 Would you be willing to sponsor my upload?

   Yes, I can do it if regular maintainers do not oppose and do
 not react to your proposed patch.

No objections here. Andreas is the usual nvidia-cuda-toolkit uploader
but he seems to have gone MIA for a while.

Regards,
Vincent


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

Bug#758478: libguac-client-rdp0: Please rebuild / binNMU against libfreerdp-1.1

[Vincent Cheng]

On Sun, 17 Aug 2014 23:03:22 +0200 Dominik George
dominik.geo...@teckids.org wrote:
 Package: libguac-client-rdp0
 Version: 0.8.3-1+b1
 Severity: grave
 Justification: renders package unusable

 libfreerdp1 changed its soname without renaming the package, which broke
 the dependency.

#757605

Also, if you'd like to see the package binNMU'ed, your point of
contact isn't the maintainer, it's the release team (via the
release.debian.org pseudo-package).

Regards,
Vincent


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

Bug#753705: fixed in NEW

[Vincent Cheng]

Pinging these bug reports to delay autoremoval of conky from testing.
These RC bugs are fixed in conky/1.9.0-5, which I just uploaded to NEW
moments ago and should soon show up as [1].

Regards,
Vincent

[1] https://ftp-master.debian.org/new/conky_1.9.0-5.html


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

Bug#759887: conky: FTBFS: configure: error: Package requirements (audacious = 1.4.0 audclient dbus-glib-1 glib-2.0 gobject-2.0) were not met

[Vincent Cheng]

forcemerge 753705 759887
thanks

On Sat, Aug 30, 2014 at 12:56 PM, Lucas Nussbaum
lu...@lucas-nussbaum.net wrote:
 Source: conky
 Version: 1.9.0-4
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140830 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.

 Relevant part (hopefully):
 checking for fopencookie... yes
 checking for funopen... no
 checking ncurses.h usability... yes
 checking ncurses.h presence... yes
 checking for ncurses.h... yes
 configure: error: Package requirements (audacious = 1.4.0 audclient 
 dbus-glib-1 glib-2.0 gobject-2.0) were not met

 No package 'audclient' found

This has already been reported as #753705, but thanks for the bug report anyhow.

Regards,
Vincent


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

Bug#757120: #757120: The package doesn't build the debian file

[Vincent Cheng]

On Tue, 5 Aug 2014 14:45:13 +0100 Gianfranco Costamagna
costamagnagianfra...@yahoo.it wrote:
 Package: googleearth-package
 Version: 1.1.0
 Severity: serious
 Justification: makes the program almost useless

 tags:patch


 the fix is fairly trivial, taken from the ubuntu bug report
 https://bugs.launchpad.net/ubuntu/+source/googleearth-package/+bug/1335021

Assuming that the problem is not being able to produce a binary
package with make-googleearth-package, I can't reproduce this at all:

$ make-googleearth-package
--2014-08-19 01:15:09--
http://dl.google.com/earth/client/current/GoogleEarthLinux.bin
[...]
dpkg-deb: building package `googleearth' in
`./googleearth_6.0.3.2197+1.1.0-1_amd64.deb'.
-
Success!
You can now install the package with e.g:

sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_amd64.deb
-

Should this still be a RC bug?

Regards,
Vincent


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

Bug#753705: conky is marked for autoremoval from testing

[Vincent Cheng]

On Thu, Aug 7, 2014 at 9:39 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 conky 1.9.0-4 is marked for autoremoval from testing on 2014-08-17

 It is affected by these RC bugs:
 753705: conky: FTBFS with audacious 3.5: libaudclient removed


Just pinging this bug to delay autoremoval; still waiting for
libaudclient to get through NEW.

Regards,
Vincent


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

Bug#757648: Supertuxkart included non-free images.

[Vincent Cheng]

Hi ftpmasters,

On Sun, Aug 10, 2014 at 1:51 AM, mejiko
kame55-itasenpara...@y2.dion.ne.jp wrote:
 Package: supertuxkart
 Severity: serious

 Hello.

 Supertuxkart included non-free images. This is supertux images.

 supertux image used Superman logo.

 It is not distributable, Its non-free.


 File List:

 data/gui/diffculty_best.png

[...]

 Reference:

 http://www.dccomics.com/copyright
 http://www.dccomics.com/terms-of-use
 https://bugzilla.redhat.com/show_bug.cgi?id=1128410
 https://trisquel.info/en/issues/12151

Is the referenced file (installed as
/usr/share/games/supertuxkart/data/gui/difficulty_best.png by
supertuxkart-data) distributable or not? I'd like to have an
authoritative answer before either closing this bug or pushing back on
upstream (who don't agree with the bug reporter [1]).

Regards,
Vincent

[1] https://github.com/supertuxkart/stk-code/issues/1446


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

Bug#755327: gridsite: FTBFS: htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)

[Vincent Cheng]

Hi Gianfranco,

On Sun, Aug 3, 2014 at 1:02 AM, Gianfranco Costamagna
costamagnagianfra...@yahoo.it wrote:

 I see, the copy-pasted stripped the tab

 + #define HTCP_GET1
 + #define HTCP_PUT2
 + #define HTCP_DELETE3

 + #define HTCP_GET  1
 + #define HTCP_PUT  2
 + #define HTCP_DELETE   3

 maybe next time I'll send the patch as attachment, to avoid this kind of 
 problems

Ah, that explains it. Sorry, I didn't realize you already had a
package up on mentors, please link it along with your debdiff next
time.

 Aside from that, I have to say that I prefer Colin's proposed debdiff
 rather than yours; testing for older versions of curl rather than just
 getting rid of legacy code is the right approach and makes it easier
 to backport this package if desired.


 I have _nothing_ against Colin's approach (we already discussed it a little 
 on irc).

 But look at the define
 ++#if (LIBCURL_VERSION_NUM  0x070907)

 do you want to really to backport this package to a system with a curl 
 packaged in 2002???
 curl (7.9.7-1) unstable; urgency=low
 Wed, 15 May 2002 21:09:19 +0200


 oldstable has already 7.21, so I don't see the point in maintaining such 
 code, moreover because upstream
 just dropped it completely.

 So if you want to go with this approach is fine for me, since ubuntu already 
 took the patch.

 But I still think that having an upstream commit cherry-picked (alrady used 
 by fedora people) can help in maintaining the code
 https://github.com/CESNET/gridsite/commit/2124d471f9fc1eed4bf5893ed2701350357c01af

 http://pkgs.fedoraproject.org/cgit/gridsite.git/tree/curl-opts.patch

I'm still of the opinion that Colin's approach is a more
technically-correct one, but either debdiff fixes this build failure,
and ultimately it's up to gridsite's maintainer to choose the approach
they prefer (once they start actively working on their package again).
*shrugs*

Regards,
Vincent


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

Bug#753705: conky: FTBFS with audacious 3.5: libaudclient removed

[Vincent Cheng]

Hi Andrew,

On Thu, Jul 31, 2014 at 8:12 AM, Andrew Shadura and...@shadura.me wrote:
 Hello,

 On Tue, 8 Jul 2014 14:18:15 +0100 Colin Watson cjwat...@ubuntu.com
 wrote:
  It looks like upstream hasn't done any porting work to drop
  libaudclient, and nobody else has done so either; e.g. Fedora has
  gone ahead and just dropped audacious support [1], so I plan on
  doing the same thing soon unless someone steps up with a patch.

 Thanks.  That sounds reasonable - please do.

 Upstream says the interface has been deprecated since 2009, and MPRIS
 2.0 should be used instead.

 However, I have packaged libaudclient as a separate package, and it's
 in NEW now.

That's great, thanks! I'll make a note to myself to keep track of its
status in NEW and fix conky's build-deps once it gets through. (I'm
also waiting on nvidia-settings to get through NEW for libxnvctrl,
ideally they'll pass through NEW at roughly the same time so I can get
everything done in a single upload...)

Regards,
Vincent


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

Bug#750605: screen goes berserk, had to downgrade

[Vincent Cheng]

On Thu, Jul 31, 2014 at 1:44 AM, 積丹尼 Dan Jacobson jida...@jidanni.org wrote:
 found 750605 2:2.99.914-1~exp1
 thanks

 ma == maximilian attems m...@stro.at writes:
 ma On Thu, Jun 05, 2014 at 05:33:21PM +0800, 積丹尼 Dan Jacobson wrote:
  VC == Vincent Cheng vch...@debian.org writes:
 VC Section Device
 VC Identifier  Intel Graphics
 VC Driver  intel
 VC Option  AccelMethod  uxa
 VC EndSection
 Indeed, that fixes it.


 ma Newer snapshat has sna fixes, please test 2:2.99.911+git20140607-1~exp1
 ma (without uxa fallback)

 Bug still remains and is very bad in 2:2.99.914-1~exp1 .

Again, this sounds like an upstream bug, so please report it upstream [1].

Regards,
Vincent

[1] https://01.org/linuxgraphics/documentation/how-report-bugs


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

Bug#755327: gridsite: FTBFS: htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)

[Vincent Cheng]

Hi Gianfranco,

Your proposed debdiff doesn't seem to apply cleanly (did you actually
test it?)...

dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building gridsite using existing ./gridsite_2.0.4.orig.tar.gz
patching file src/htcp.c
Hunk #1 FAILED at 59.
1 out of 1 hunk FAILED
dpkg-source: info: fuzz is not allowed when applying patches
dpkg-source: info: if patch 'curl-defines.patch' is correctly applied
by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E
-b -B .pc/curl-defines.patch/ --reject-file=- 
gridsite-2.0.4.orig.cAX2KS/debian/patches/curl-defines.patch gave
error exit status 1
dpkg-buildpackage: error: dpkg-source -b gridsite-2.0.4 gave error exit status 2

Aside from that, I have to say that I prefer Colin's proposed debdiff
rather than yours; testing for older versions of curl rather than just
getting rid of legacy code is the right approach and makes it easier
to backport this package if desired.

Regards,
Vincent


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

Bug#755327: gridsite: FTBFS: htcp.c:65:27: error: 'CURLOPT_FILE' undeclared (first use in this function)

[Vincent Cheng]

Dear maintainer,

I've prepared an NMU for gridsite (versioned as 2.0.4-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer.

Regards,
Vincent


diff -Nru gridsite-2.0.4/debian/changelog gridsite-2.0.4/debian/changelog
--- gridsite-2.0.4/debian/changelog 2014-05-12 06:51:28.0 -0700
+++ gridsite-2.0.4/debian/changelog 2014-08-02 19:03:01.0 -0700
@@ -1,3 +1,13 @@
+gridsite (2.0.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Colin Watson ]
+  * Test for old curl by version rather than with #ifndef, which breaks as
+of curl 7.37.1 (closes: #755327).
+
+ -- Vincent Cheng vch...@debian.org  Sat, 02 Aug 2014 19:02:02 -0700
+
 gridsite (2.0.4-3) unstable; urgency=medium

   * Add missing Build-Requires on pkg-config (Closes: #747768)
diff -Nru gridsite-2.0.4/debian/patches/curl-defines.patch
gridsite-2.0.4/debian/patches/curl-defines.patch
--- gridsite-2.0.4/debian/patches/curl-defines.patch 1969-12-31
16:00:00.0 -0800
+++ gridsite-2.0.4/debian/patches/curl-defines.patch 2014-08-02
19:01:36.0 -0700
@@ -0,0 +1,44 @@
+Description: Test for old curl by version rather than with #ifndef
+ As of curl 7.37.1, CURLOPT_READDATA and CURLOPT_WRITEDATA are enums rather
+ than #defines and the old names are #defines instead; testing for them with
+ #ifndef results in #define loops.  Use a version test instead to find out
+ whether we need compatibility definitions.
+Author: Colin Watson cjwat...@ubuntu.com
+Bug-Debian: https://bugs.debian.org/755327
+Forwarded: no
+Last-Update: 2014-07-31
+
+Index: b/src/htcp.c
+===
+--- a/src/htcp.c
 b/src/htcp.c
+@@ -61,11 +61,8 @@
+
+ /* deal with older versions of libcurl and curl.h */
+
+-#ifndef CURLOPT_WRITEDATA
++#if (LIBCURL_VERSION_NUM  0x070907)
+ #define CURLOPT_WRITEDATA CURLOPT_FILE
+-#endif
+-
+-#ifndef CURLOPT_READDATA
+ #define CURLOPT_READDATA CURLOPT_FILE
+ #endif
+
+Index: b/src/slashgrid.c
+===
+--- a/src/slashgrid.c
 b/src/slashgrid.c
+@@ -89,11 +89,8 @@
+
+ #define GRST_SLASH_HTCP_PORT 777
+
+-#ifndef CURLOPT_WRITEDATA
++#if (LIBCURL_VERSION_NUM  0x070907)
+ #define CURLOPT_WRITEDATA CURLOPT_FILE
+-#endif
+-
+-#ifndef CURLOPT_READDATA
+ #define CURLOPT_READDATA CURLOPT_INFILE
+ #endif
+
diff -Nru gridsite-2.0.4/debian/patches/series
gridsite-2.0.4/debian/patches/series
--- gridsite-2.0.4/debian/patches/series 2014-05-12 06:46:46.0 -0700
+++ gridsite-2.0.4/debian/patches/series 2014-08-02 19:01:36.0 -0700
@@ -3,3 +3,4 @@
 gridsite-httpd24.patch
 gridsite-fprintf.patch
 gridsite-return-type.patch
+curl-defines.patch


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

On Sun, Jul 27, 2014 at 9:39 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 codeblocks 13.12-3 is marked for autoremoval from testing on 2014-07-31

 It is affected by these RC bugs:
 744115: codeblocks: Please update to use wxwidgets3.0



Ping.


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

Bug#740565: redeclipse-data: should be in main

[Vincent Cheng]

On Sun, Jul 27, 2014 at 6:30 AM, Markus Koschany a...@gambaru.de wrote:
 On 27.07.2014 10:23, Martin Erik Werner wrote:
 [...]
 As far as I see it, it is still uncertain whether redeclipse-data
 belonging in main is a correct assumption, a re-review of the content
 would be needed, from the previous discussion I think it is indeed
 *probable* that it would be found fit for main.

 I have reviewed redeclipse and redeclipse-data file-by-file. The patches
 are now attached to this bug report. The licenses are DFSG-free and
 there is not a single file that wouldn't abide by the rules. The only
 thing I noticed was a missing license paragraph about a few public
 domain images which I have added to debian/copyright. The paragraph
 about the Play* fonts could be removed because it appears you moved the
 font to a separate package, fonts-play. Otherwise the copyright file was
 accurate.

Great, thanks for the patches! I'm sure you've realized by now that
the fastest way to get stuff done in Debian is to do it yourself. ;)

 I don't think this is an RC bug, since keeping it in nonfree is actually
 the safer option (albeit a bad one should it be deemed unnecessary).

 No, this is, was and always will be RC. Fixing this issue during a
 regular upload was preferable but it seems there won't be another
 release in time before the freeze thus it was necessary to finally take
 action.

No, it's not RC; see below.

 Imagine the gnome-shell maintainers decided to put their package into
 non-free because they felt it is safer. It would make all dependencies
 suddenly uninstallable. You simply can't make arbitrary decisions about
 the archive sections. Just because Red Eclipse is just a game makes
 the issue not smaller or less important.

Yes, the gnome-shell maintainers can decide to put their packages into
non-free if they so wish; doing so is not a Policy violation, even if
it sounds ridiculous. And yes, it would make their dependencies
uninstallable, which would indeed lead to RC bugs being filed against
it and/or its dependencies (and would likely be followed by some
heated flamewars on certain mailing lists). It's completely
hypothetical, but the gnome-shell maintainers can move their package
to non-free at any time, and only the CTTE can override them.

 There is no documented Policy about the term safer but the Policy is
 very precise about Debian's archive areas. [1] If your package is
 compliant with the DFSG it must be in main because this area comprises
 the Debian distribution. Otherwise other software, like my games-fps
 metapackage from the Debian Games Pure Blend, is not allowed to depend
 or recommend Red Eclipse. Since Red Eclipse is DFSG-free it is a Policy
 violation. Thus the severity must be serious.

No, Policy §2.2 explicitly states that non DFSG compliant packages
must go in non-free, but nothing about DFSG compliant packages being
forced to be distributed in main. 2.2.1 only says that Every package
in main must comply with the DFSG (Debian Free Software Guidelines),
i.e. package in main - DFSG-compliant, _not_ the reverse. Policy
doesn't forbid placing DFSG packages in contrib or non-free, as silly
as it may sound, so this simply isn't a RC bug.

Just to be clear, I don't object to placing DFSG-free packages in
main; what I'm arguing against is inflating bug severity to accomplish
your own personal release goals when the bug doesn't violate Policy.
It may be important to you, but if it doesn't meet the definition of a
RC bug, it's not a RC bug, and it's definitely not a release blocker.
Now, just imagine if every maintainer and user decided to inflate the
priority of their own pet bugs...

Regards,
Vincent


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

Bug#740565: redeclipse-data: should be in main

[Vincent Cheng]

On Sun, Jul 27, 2014 at 9:46 AM, Martin Erik Werner
martinerikwer...@gmail.com wrote:
 On Sun, 2014-07-27 at 15:30 +0200, Markus Koschany wrote:
 On 27.07.2014 10:23, Martin Erik Werner wrote:
 [...]
  As far as I see it, it is still uncertain whether redeclipse-data
  belonging in main is a correct assumption, a re-review of the content
  would be needed, from the previous discussion I think it is indeed
  *probable* that it would be found fit for main.

 I have reviewed redeclipse and redeclipse-data file-by-file. The patches
 are now attached to this bug report. The licenses are DFSG-free and
 there is not a single file that wouldn't abide by the rules. The only
 thing I noticed was a missing license paragraph about a few public
 domain images which I have added to debian/copyright. The paragraph
 about the Play* fonts could be removed because it appears you moved the
 font to a separate package, fonts-play. Otherwise the copyright file was
 accurate.

 Thank you for the review, it is very much appreciated! Both font and P-D
 corrections looks correct (I previously think I let the P-D stuff fall
 through to the Files: * CC-BY-SA glob since they had been modified in
 Red Eclipse), but I think this makes more sense on second thought.

 I have pushed your changes to the git repos for redeclipse.

 Anyone up for sponsoring redeclipse and redeclipse-data for this change?

Sure, put it on the team sponsor queue [1] and I'll take a look at it
eventually (before the freeze, at worst) if nobody else does.

Regards,
Vincent

[1] https://wiki.debian.org/Games/Sponsors/Queue


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

Bug#740565: redeclipse-data: should be in main

[Vincent Cheng]

On Sun, Jul 27, 2014 at 1:23 AM, Martin Erik Werner
martinerikwer...@gmail.com wrote:
 On Sat, 2014-07-26 at 15:07 -0700, Vincent Cheng wrote:
 On Sat, Jul 26, 2014 at 4:53 AM, Markus Koschany a...@gambaru.de wrote:
  Control: severity -1 serious
 
  There is not much time left until the freeze happens. Unfortunately NEW
  processing is not very fast nowadays. We should take action on this bug
  and upload redeclipse and redeclipse-data to main as soon as possible.
 

 How is this a RC bug? We all have personal release goals that we want
 to get done before the freeze, but that doesn't justify it being RC.
 Also, bumping the severity of this bug as RC seems counterintuitive as
 it could just lead to the package being auto-removed from testing...

 As far as I see it, it is still uncertain whether redeclipse-data
 belonging in main is a correct assumption, a re-review of the content
 would be needed, from the previous discussion I think it is indeed
 *probable* that it would be found fit for main.

 I don't think this is an RC bug, since keeping it in nonfree is actually
 the safer option (albeit a bad one should it be deemed unnecessary).

Agreed. I'd argue that it's best to downgrade the priority on the bug,
and then work on assessing the package and moving to main if deemed
appropriate. Having the package in contrib/non-free in jessie is
better than not having the package in jessie, after all.

Martin, please feel free to go ahead and downgrade the bug's severity.

Regards,
Vincent


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

Bug#740565: redeclipse-data: should be in main

[Vincent Cheng]

On Sat, Jul 26, 2014 at 4:53 AM, Markus Koschany a...@gambaru.de wrote:
 Control: severity -1 serious

 There is not much time left until the freeze happens. Unfortunately NEW
 processing is not very fast nowadays. We should take action on this bug
 and upload redeclipse and redeclipse-data to main as soon as possible.


How is this a RC bug? We all have personal release goals that we want
to get done before the freeze, but that doesn't justify it being RC.
Also, bumping the severity of this bug as RC seems counterintuitive as
it could just lead to the package being auto-removed from testing...

Regards,
Vincent


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

Bug#755730: libgl1-nvidia-glx:i386: trying to overwrite shared '/usr/share/doc/libgl1-nvidia-glx/changelog.Debian.gz'

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

On Tue, Jul 22, 2014 at 12:43 PM, George Shuklin ama...@desunote.ru wrote:
 Package: libgl1-nvidia-glx
 Version: 340.24-2
 Severity: serious
 Justification: Policy 7.6.1

 When both :amd64 and :i386 packages installing (as nvidia-driver suggests),
 dpkg reports:

 Preparing to unpack .../libgl1-nvidia-glx_340.24-2_i386.deb ...
 Unpacking libgl1-nvidia-glx:i386 (340.24-2) ...
 dpkg: error processing archive /var/cache/apt/archives/libgl1-nvidia-
 glx_340.24-2_i386.deb (--unpack):
  trying to overwrite shared '/usr/share/doc/libgl1-nvidia-
 glx/changelog.Debian.gz', which is different from other instances of package
 libgl1-nvidia-glx:i386

 Errors were encountered while processing:
  /var/cache/apt/archives/libgl1-nvidia-glx_340.24-2_i386.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 Failed to perform requested operation on package.  Trying to recover:
 dpkg: dependency problems prevent configuration of libgl1-nvidia-glx-i386:
  libgl1-nvidia-glx-i386 depends on libgl1-nvidia-glx; however:
   Package libgl1-nvidia-glx:i386 is not installed.


I have multiarch enabled, and both libgl1-nvidia-glx:amd64 and
libgl1-nvidia-glx:i386 installed, but I can't reproduce this
(otherwise I certainly wouldn't have gone ahead and uploaded
nvidia-graphics-drivers anyways). Can you please attach a copy of
/var/log/apt/history.log and /var/log/apt/term.log to this bug report?
I'm curious to see what combination of upgraded packages could have
caused this.

(Also, a nitpick: Policy 7.6.1 has nothing to do with multiarch skew,
which is what this looks like.)

Regards,
Vincent


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

Bug#755116: [xorg] impossible execute startx

[Vincent Cheng]

reassign 755116 nvidia-graphics-drivers
forcemerge 755138 755116
thanks

Merging duplicate bugs (and thus closing). The root issue is that
nvidia-graphics-drivers wasn't updated in time for the xserver 1.16
transition and ABI bump, and was thus temporarily unavailable /
non-installable. Fixed in nvidia-graphics-drivers/340.24-1.

Regards,
Vincent


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

Bug#751082: Non-free Nvidia driver (340.24) upload pending

[Vincent Cheng]

Hi,

For those interested in the state of the current non-free nvidia blob
in unstable, I intend on uploading the latest stable version, 340.24
(which has support for xserver 1.16), within a day. I've pushed
updating packaging files to [1] and a freshly generated tarball to
[2]; please feel free to build and test.

[1] svn://svn.debian.org/svn/pkg-nvidia/packages/nvidia-graphics-drivers/trunk/
[2] 
svn://svn.debian.org/svn/pkg-nvidia/tarballs/nvidia-graphics-drivers_340.24.orig.tar.gz

I also intend to upload fresh copies of nvidia-settings,
nvidia-xconfig, and the latest legacy nvidia 304.xxx branch shortly
after.

Regards,
Vincent


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

On Mon, Jul 7, 2014 at 9:39 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 codeblocks 13.12-3 is marked for autoremoval from testing on 2014-07-16

 It is affected by these RC bugs:
 744115: codeblocks: Please update to use wxwidgets3.0



Ping...


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

Bug#753241: nsnake: FTBFS: dpkg-source: error: expected ^--- in line 4 of diff `nsnake-1.5/debian/patches/hardening.patch'

[Vincent Cheng]

Control: tag -1 + pending

Dear maintainer,

I've prepared an NMU for nsnake (versioned as 1.5-1.1) and uploaded it
to DELAYED/2. Please feel free to tell me if I should delay it longer.

Regards,
Vincent


diff -Nru nsnake-1.5/debian/changelog nsnake-1.5/debian/changelog
--- nsnake-1.5/debian/changelog 2013-04-24 01:14:32.0 +0200
+++ nsnake-1.5/debian/changelog 2014-07-11 10:00:45.0 +0200
@@ -1,3 +1,13 @@
+nsnake (1.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Juhani Numminen ]
+  * Tweak hardening.patch to fix a missing newline
+(Closes: #753241)
+
+ -- Gianfranco Costamagna costamagnagianfra...@yahoo.it  Fri, 11
Jul 2014 09:59:31 +0200
+
 nsnake (1.5-1) unstable; urgency=low

   * Initial release (Closes: #706048)
diff -Nru nsnake-1.5/debian/patches/hardening.patch
nsnake-1.5/debian/patches/hardening.patch
--- nsnake-1.5/debian/patches/hardening.patch 2013-04-23
22:31:46.0 +0200
+++ nsnake-1.5/debian/patches/hardening.patch 2014-07-11
09:58:53.0 +0200
@@ -1,6 +1,7 @@
 Description: Applied hardening flags to build process.
 Author: Alexandre Dantas alex.danta...@gmail.com
-Last-Update: 2013-04-23--- a/Makefile
+Last-Update: 2013-04-23
+--- a/Makefile
 +++ b/Makefile
 @@ -57,9 +57,11 @@
  CC = gcc


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

Bug#753241: nsnake: FTBFS: dpkg-source: error: expected ^--- in line 4 of diff `nsnake-1.5/debian/patches/hardening.patch'

[Vincent Cheng]

Hi Alexandre,

On Sat, Jul 12, 2014 at 2:34 PM, Alexandre Dantas e...@alexdantas.net wrote:
 Hello Vincent,
 thanks for your concern!

 I've already fixed bugs #753241 [0] and #737978 [1] on the
 Git repository and am currently waiting for sponsor Anton
 Gladky to review them.

 I'm also currently working on #740914, since the latest
 nsnake version doesn't depend on a package that's not
 on Debian anymore.

In that case, would you like me to remove my delayed upload from the
queue, or would you rather keep it there so that the FTBFS bug is at
least fixed while you're waiting on your sponsor to review your next
upload?

Regards,
Vincent


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

Bug#753241: nsnake: FTBFS: dpkg-source: error: expected ^--- in line 4 of diff `nsnake-1.5/debian/patches/hardening.patch'

[Vincent Cheng]

On Sat, Jul 12, 2014 at 4:15 PM, Alexandre Dantas e...@alexdantas.net wrote:
 Hi Vincent,

 my sponsor told me he'd review the packages this weekend,
 so I prefer if you'd remove the delayed upload.

Ok, done.

Regards,
Vincent


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

Bug#753705: conky: FTBFS with audacious 3.5: libaudclient removed

[Vincent Cheng]

On Fri, Jul 4, 2014 at 6:20 AM, Colin Watson cjwat...@ubuntu.com wrote:
 Package: conky
 Version: 1.9.0-4
 Severity: serious

 conky fails to build with audacious 3.5-1 in unstable:

   configure: error: Package requirements (audacious = 1.4.0 audclient 
 dbus-glib-1 glib-2.0 gobject-2.0) were not met:

   No package 'audclient' found

 http://audacious-media-player.org/news/27-audacious-3-5-released says
 that libaudclient has been removed upstream, apparently in favour of
 newer GDBus-based code.  Perhaps it's possible to adapt conky to that?

Thanks for the bug report!

It looks like upstream hasn't done any porting work to drop
libaudclient, and nobody else has done so either; e.g. Fedora has gone
ahead and just dropped audacious support [1], so I plan on doing the
same thing soon unless someone steps up with a patch.

Regards,
Vincent

[1] https://bugzilla.redhat.com/1090655


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

On Tue, Jun 17, 2014 at 9:39 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 codeblocks 13.12-3 is marked for autoremoval from testing on 2014-07-02

 It is affected by these RC bugs:
 744115: codeblocks: Please update to use wxwidgets3.0


Pinging this bug report again to delay autoremoval; according to the
forwarded bug report, it sounds like upstream is going to take a look
at this.

Regards,
Vincent


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

Bug#751130: vtk: FTBFS: undefined reference to `vtkPostgreSQLDatabase::New()'

[Vincent Cheng]

Dear maintainer,

I've prepared an NMU for vtk (versioned as 5.8.0-17.3) and uploaded it
to DELAYED/2. Please feel free to tell me if I should delay it longer.

Regards,
Vincent

Debdiff is as follows:

diff -Nru vtk-5.8.0/debian/changelog vtk-5.8.0/debian/changelog
--- vtk-5.8.0/debian/changelog 2014-05-17 07:48:41.0 -0700
+++ vtk-5.8.0/debian/changelog 2014-06-25 04:00:48.0 -0700
@@ -1,3 +1,12 @@
+vtk (5.8.0-17.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Colin Watson]
+  * Look for PostgreSQL libraries in multiarch locations (closes: #751130).
+
+ -- Gianfranco Costamagna costamagnagianfra...@yahoo.it  Wed, 25
Jun 2014 13:00:11 +0200
+
 vtk (5.8.0-17.2) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru vtk-5.8.0/debian/patches/multiarch-libpq.patch
vtk-5.8.0/debian/patches/multiarch-libpq.patch
--- vtk-5.8.0/debian/patches/multiarch-libpq.patch 1969-12-31
16:00:00.0 -0800
+++ vtk-5.8.0/debian/patches/multiarch-libpq.patch 2014-06-25
01:38:31.0 -0700
@@ -0,0 +1,38 @@
+Description: Look for PostgreSQL libraries in multiarch locations
+Author: Colin Watson cjwat...@ubuntu.com
+Bug-Debian: https://bugs.debian.org/751130
+Forwarded: no
+Last-Update: 2014-06-23
+
+Index: b/CMake/FindPOSTGRES.cmake
+===
+--- a/CMake/FindPOSTGRES.cmake
 b/CMake/FindPOSTGRES.cmake
+@@ -14,6 +14,11 @@
+   find_library( POSTGRES_LIBRARIES
+ NAMES pq libpq
+ PATHS
++  ${_POSTGRES_DIR}/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++  ${CMAKE_INSTALL_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++  /usr/local/pgsql/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++  /usr/local/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++  /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}
+   ${_POSTGRES_DIR}/lib64
+   ${CMAKE_INSTALL_PREFIX}/lib64
+   /usr/local/pgsql/lib64
+Index: b/CMake/FindPQXX.cmake
+===
+--- a/CMake/FindPQXX.cmake
 b/CMake/FindPQXX.cmake
+@@ -13,6 +13,11 @@
+ find_library( PQXX_LIBRARY
+   NAMES libpqxx pqxx
+   PATHS
++${_PQXX_DIR}/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++${CMAKE_INSTALL_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++/usr/local/pgsql/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++/usr/local/lib/${CMAKE_LIBRARY_ARCHITECTURE}
++/usr/lib/${CMAKE_LIBRARY_ARCHITECTURE}
+ ${_PQXX_DIR}/lib
+ ${_PQXX_DIR}
+ ${CMAKE_INSTALL_PREFIX}/lib
diff -Nru vtk-5.8.0/debian/patches/series vtk-5.8.0/debian/patches/series
--- vtk-5.8.0/debian/patches/series 2014-05-16 05:32:22.0 -0700
+++ vtk-5.8.0/debian/patches/series 2014-06-25 01:38:31.0 -0700
@@ -4,3 +4,4 @@
 tcl-links.patch
 libav10.patch
 java15.patch
+multiarch-libpq.patch


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

Bug#749939: libapache2-mod-ruwsgi: /usr/lib/apache2/modules/mod_Ruwsgi.so file is missing in the package content for wheezy

[Vincent Cheng]

close 749939
thanks

I can't reproduce this; /usr/lib/apache2/modules/mod_Ruwsgi.so is
present in the libapache2-mod-ruwsgi package in wheezy:

https://packages.debian.org/wheezy/amd64/libapache2-mod-ruwsgi/filelist

You can also check for yourself:

$ apt-get download libapache2-mod-ruwsgi
$ dpkg-deb -x libapache2-mod-ruwsgi_1.2.3+dfsg-5+deb7u1_amd64.deb .
$ file usr/lib/apache2/modules/mod_Ruwsgi.so
usr/lib/apache2/modules/mod_Ruwsgi.so: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=5eb40d3108f4b243e5858b6701d35feed13b9825, stripped

Regards,
Vincent


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

On Mon, Jun 16, 2014 at 9:11 PM, Olly Betts o...@survex.com wrote:
 On Mon, Jun 16, 2014 at 08:59:33PM -0700, Vincent Cheng wrote:
 This fell off my radar, sorry! Pinging the bug report to delay
 autoremoval from testing.

 It would be nice if you also actually responded to my last message
 (which I sent over 2 months ago).  For your convenience I repeat it
 here:

Sorry, must have missed that as well!

 ---

 I just tried to reproduce the issue described in #736368 using my
 13.12-3.1 build, but I couldn't follow the steps described:

 | If I open a .c file,

 Ctrl+O and enter a path to a C file - OK

 | double click on a variable to mark it,

 Double click on a variable in the pane with the source code in - OK.

 | right click

 Menu appears - OK.

 | and selects from the menu permanentely highlight variable

 There's no such entry in the menu I have (or in any of its submenus).

You'll need to install codeblocks-contrib first (the permanently
highlight variable function is implemented as a plugin). I can
reproduce the bug with codeblocks/13.12-1 (built with wx 3.0), but not
codeblocks/13.12-3 (built with wx 2.8).

Regards,
Vincent


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

Bug#744115: codeblocks is marked for autoremoval from testing

[Vincent Cheng]

forwarded 744115 https://sourceforge.net/p/codeblocks/tickets/17/
thanks

On Wed, May 28, 2014 at 9:39 PM, Debian testing autoremoval watch
nore...@release.debian.org wrote:
 codeblocks 13.12-3 is marked for autoremoval from testing on 2014-06-13

 It is affected by these RC bugs:
 744115: codeblocks: Please update to use wxwidgets3.0


This fell off my radar, sorry! Pinging the bug report to delay
autoremoval from testing.

I did have a bug report on upstream's old Berlios bug tracker, but
that got closed down a while ago, so marking this as forwarded to
upstream's new sourceforge tracker.

Regards,
Vincent


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

Bug#746822: 0ad: ftbfs with GCC-4.9

[Vincent Cheng]

Control: severity -1 important

On Sat, May 3, 2014 at 5:21 PM, Matthias Klose d...@debian.org wrote:
 Package: src:0ad
 Version: 0.0.15+dfsg-3
 Severity: important
 Tags: sid jessie
 User: debian-...@lists.debian.org
 Usertags: ftbfs-gcc-4.9

 The package fails to build in a test rebuild on at least amd64 with
 gcc-4.9/g++-4.9, but succeeds to build with gcc-4.8/g++-4.8. The
 severity of this report may be raised before the jessie release.

This package only FTBFS when built with gcc 4.9 if the test suite is
run during the build process, and I disabled the test suite as of
0.0.16-1 due to some other unrelated test failures, hence I'm
downgrading the severity of this bug report (instead of closing it,
since I intend to re-enable the test suite once upstream fixes it).

Regards,
Vincent


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

Bug#750605: screen goes berserk, had to downgrade

[Vincent Cheng]

On Wed, Jun 4, 2014 at 4:09 PM, 積丹尼 Dan Jacobson jida...@jidanni.org wrote:
 Package: xserver-xorg-video-intel
 Version: 2:2.99.911+git20140529-1~exp2
 Severity: grave

 2:2.99.911+git20140529-1~exp2 makes screen go berserk.
 2:2.99.911+git20140529-1~exp1 works fine.


This would likely be related to SNA being made default. You can work
around this with the following xorg.conf snippet:

Section Device
Identifier  Intel Graphics
Driver  intel
Option  AccelMethod  uxa
EndSection

Please file a bug report upstream [1].

Regards,
Vincent

[1] https://01.org/linuxgraphics/documentation/how-report-bugs


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

Bug#705157: kaya: diff for NMU version 0.4.4-6.1

[Vincent Cheng]

tag 713122 + pending
tag 705157 + pending
thanks

Dear maintainer,

I've prepared an NMU for kaya (versioned as 0.4.4-6.1) and uploaded it
to DELAYED/2 (debdiff below). Please feel free to tell me if I should
delay it longer.

Regards,
Vincent


diff -Nru kaya-0.4.4/debian/changelog kaya-0.4.4/debian/changelog
--- kaya-0.4.4/debian/changelog 2012-10-10 12:35:12.0 -0700
+++ kaya-0.4.4/debian/changelog 2014-06-02 00:14:24.0 -0700
@@ -1,3 +1,20 @@
+kaya (0.4.4-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Peter Michael Green ]
+  * Remove ghc6 alternative from build-depends (Closes: 713122)
+
+  [ Iain Lane ]
+  * FTBFS fixes.
+  * debian/patches/ghc-7.6-fixes: Patches to work with API changes in GHC 7.6,
+mainly to make use of Control.Exception. (Closes: 705157)
+  * debian/patches/new-gc-api.patch: Backport of upstream commits to work with
+current boehm GC APIs
+  * Add dh_autoreconf usage for the above patch.
+
+ -- Gianfranco Costamagna costamagnagianfra...@yahoo.it  Wed, 28
May 2014 10:42:10 +0200
+
 kaya (0.4.4-6) unstable; urgency=low

   [ gregor herrmann ]
diff -Nru kaya-0.4.4/debian/control kaya-0.4.4/debian/control
--- kaya-0.4.4/debian/control 2012-10-10 12:30:48.0 -0700
+++ kaya-0.4.4/debian/control 2014-05-28 01:39:47.0 -0700
@@ -2,7 +2,7 @@
 Section: devel
 Priority: extra
 Maintainer: Stuart Teasdale s...@debian.org
-Build-Depends: debhelper (= 7.0.0), autotools-dev, ghc6 | ghc,
libghc-mtl-dev, libgc-dev, happy, libpcre3-dev(= 5.0),
libgcrypt11-dev, libncurses5-dev, freeglut3-dev, zlib1g-dev,
libgnutls-dev, libpq-dev, libmysqlclient-dev, libsqlite3-dev,
libgd2-xpm-dev, libsdl1.2-dev,libncursesw5-dev,libghc-editline-dev,
libghc-random-dev
+Build-Depends: debhelper (= 7.0.0), autotools-dev, ghc,
libghc-mtl-dev, libgc-dev, happy, libpcre3-dev(= 5.0),
libgcrypt11-dev, libncurses5-dev, freeglut3-dev, zlib1g-dev,
libgnutls-dev, libpq-dev, libmysqlclient-dev, libsqlite3-dev,
libgd2-xpm-dev, libsdl1.2-dev,libncursesw5-dev,libghc-editline-dev,
libghc-random-dev, dh-autoreconf
 Standards-Version: 3.8.3
 Homepage: http://kayalang.org/

diff -Nru kaya-0.4.4/debian/patches/ghc-7.6-fixes
kaya-0.4.4/debian/patches/ghc-7.6-fixes
--- kaya-0.4.4/debian/patches/ghc-7.6-fixes 1969-12-31 16:00:00.0 -0800
+++ kaya-0.4.4/debian/patches/ghc-7.6-fixes 2014-05-28 01:39:47.0 -0700
@@ -0,0 +1,115 @@
+Description: Fix build with changed APIs in GHC 7.6
+Author: Iain Lane iain.l...@canonical.com
+Forwarded: yes
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705157
+
+Index: b/compiler/Driver.hs
+===
+--- a/compiler/Driver.hs
 b/compiler/Driver.hs
+@@ -28,6 +28,7 @@
+ import ProgramDump
+ import REPL
+
++import Control.Exception
+ import System.Cmd
+ import System.Exit
+ import System.Directory
+@@ -67,8 +68,8 @@
+catch (do startup - getStartup prtype libdirs
+  let pt = addToPT (parse newroot libdirs
(prog++startup) fn) pinput
+  compile newroot libdirs opts pt extra mainfile)
+- (\e - do putStrLn (show e)
+-   return CompError)
++ (\(e :: IOException) - do putStrLn (show e)
++return CompError)
+
+ outputfile Module mod = showuser mod ++ .o
+ -- TMP HACK: This should probably be a %extension cgi directive in the .ks
+Index: b/compiler/Module.hs
+===
+--- a/compiler/Module.hs
 b/compiler/Module.hs
+@@ -14,8 +14,9 @@
+   getAllLibDirs, linkFiles, getObjs) where
+
+ import Language
++import Control.Exception
+ import Debug.Trace
+-import System.Directory
++import System.Directory (doesFileExist)
+ import Data.List
+ import Lib
+ import Options
+@@ -244,7 +245,7 @@
+  (do --putStrLn $ Trying  ++ x ++ path
+ f - readFile (x++path)
+ return (Just f))
+- (\e - findFile xs path)
++ (\(e :: IOException) - findFile xs path)
+
+ -- Get all the library directories, looking at the options and the
+ -- KAYA_LIBRARY_PATH environment variable.
+Index: b/compiler/Portability64.hs
+===
+--- a/compiler/Portability64.hs
 b/compiler/Portability64.hs
+@@ -1,6 +1,7 @@
+ module Portability64 where
+
+ import Lib
++import Control.Exception
+ import System.IO
+ import System.Environment
+ import qualified Data.Map as Map
+@@ -10,7 +11,7 @@
+ environment :: String - IO (Maybe String)
+ environment x = catch (do e - getEnv x
+  return (Just e))
+-  (\_ - return Nothing)
++  (\(_ :: IOException) - return Nothing)
+
+ tempfile :: IO (FilePath, Handle)
+ tempfile = do env - environment TMPDIR
+Index: b/compiler/CodegenCPP.hs
+===
+--- a/compiler/CodegenCPP.hs
 b/compiler/CodegenCPP.hs
+@@ -11,6 +11,7 @@
+ import 

Bug#743685: urwid: FTBFS: test failures

[Vincent Cheng]

reopen 743685
thanks

On Fri, May 16, 2014 at 2:59 AM, Vincent Cheng vch...@debian.org wrote:
 On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic
 dejan.latino...@imgtec.com wrote:


 Debian patch that removes test_vterm.py
 is attached.

 Vincent, could you please include this patch
 in new Debian package version?

 Thanks, I'll take a look at this asap.

 Ian: it doesn't have to be fixed in upstream right now, no, but it'd
 be nice to have those tests removed (or fixed?) upstream as well so we
 don't end up carrying this patch in Debian forever.


Uploaded...but it looks like it's failing to build on mips now [1];
looks like the same test
(urwid.tests.test_event_loops.TwistedEventLoopTest) that failed wth
urwid/1.2.0-1. The fact that these tests don't consistently fail on
mips(el) is rather annoying. Does anyone know what's going on?

Regards,
Vincent

[1] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=mipsver=1.2.1-2stamp=1400413671


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

Bug#748509: sauerbraten: Broken in sid (dependencies cube2 and cube2-data missing)

[Vincent Cheng]

Source: sauerbraten
Version: 0.0.20140302-1
Severity: grave
Justification: renders package unusable

Filing this bug to prevent migration to testing (and so apt-listbugs users know
what's going on).

This package now depends on cube2 and cube2-data, both of which are currently
stuck in the NEW queue [1]. Sauerbraten was accepted in NEW first, thus
rendering it broken in sid.

Regards,
Vincent

[1] https://ftp-master.debian.org/new.html


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

Kernel: Linux 3.14-2-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

Versions of packages sauerbraten depends on:
ii  libc6 2.18-5
ii  libgcc1   1:4.9.0-2
ii  libgl1-mesa-glx [libgl1]  10.1.2-1
ii  libsdl-image1.2   1.2.12-5+b2
ii  libsdl-mixer1.2   1.2.12-11+b1
ii  libsdl1.2debian   1.2.15-9
ii  libstdc++64.9.0-2
ii  libx11-6  2:1.6.2-1
ii  sauerbraten-data  0.0.20130203-1
ii  zlib1g1:1.2.8.dfsg-1

Versions of packages sauerbraten recommends:
ii  sauerbraten-wake6  1.0-2

sauerbraten suggests no packages.

-- no debconf information


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

Bug#748509: sauerbraten broken in sid because cube2, cube2-data stuck in NEW

[Vincent Cheng]

Hi ftpmasters,

I was wondering if there's anything I can do in the future to prevent
bugs like #748509 from happening. My sponsoree (Markus Koschany) had
already contacted ftpmaster@ftp-master.d.o (Message-ID:
533b1ecb.7000...@gambaru.de), to which paultag replied, to let you
know that sauerbraten should not be processed in NEW without first
accepting cube2 and cube2-data, yet currently sauerbraten has just
been accepted and is now broken in sid, while cube2 and cube2-data are
stuck in NEW.

Again, what other ways are there for me to contact ftpmasters to
prevent this from happening again (if email doesn't do the trick)?

Regards,
Vincent


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

Bug#743685: urwid: FTBFS: test failures

[Vincent Cheng]

On Wed, May 14, 2014 at 9:12 AM, Dejan Latinovic
dejan.latino...@imgtec.com wrote:


 Debian patch that removes test_vterm.py
 is attached.

 Vincent, could you please include this patch
 in new Debian package version?

Thanks, I'll take a look at this asap.

Ian: it doesn't have to be fixed in upstream right now, no, but it'd
be nice to have those tests removed (or fixed?) upstream as well so we
don't end up carrying this patch in Debian forever.

Regards,
Vincent


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

Bug#741666: scribus: diff for NMU version 1.4.2.dfsg.1+r18267-0.1

[Vincent Cheng]

tag 741666 + patch
tag 741666 + pending
thanks

Dear Maintainer,

I've prepared an NMU for scribus (versioned as
1.4.2.dfsg.1+r18267-0.1) and uploaded it to DELAYED/5. Please feel
free to tell me if I should delay it longer.

The following debdiff consists of changes made to the package aside
from the removal of the non-free files in question, which generate too
much noise to be of any use in this diff.

Regards,
Vincent


diff -Nru scribus-1.4.2.dfsg+r18267/debian/changelog
scribus-1.4.2.dfsg.1+r18267/debian/changelog
--- scribus-1.4.2.dfsg+r18267/debian/changelog 2013-12-24
00:57:23.0 -0800
+++ scribus-1.4.2.dfsg.1+r18267/debian/changelog 2014-05-11
07:32:18.0 -0700
@@ -1,3 +1,11 @@
+scribus (1.4.2.dfsg.1+r18267-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Repack the source to remove some non-free contents. (Closes: #741666)
+  * debian/README.source: update to reflect the above changes.
+
+ -- Mattia Rizzolo mat...@mapreri.org  Sun, 11 May 2014 16:29:44 +0200
+
 scribus (1.4.2.dfsg+r18267-1.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru scribus-1.4.2.dfsg+r18267/debian/README.source
scribus-1.4.2.dfsg.1+r18267/debian/README.source
--- scribus-1.4.2.dfsg+r18267/debian/README.source 2011-02-11
11:25:34.0 -0800
+++ scribus-1.4.2.dfsg.1+r18267/debian/README.source 2014-05-11
07:28:04.0 -0700
@@ -19,11 +19,16 @@

 3. Remove non-free documentation and a color profile code and its license:

-rm -rf scribus-ng-1.3.5svn.dfsg~svn20090123/scribus/doc \
-scribus-ng-1.3.5svn.dfsg~svn20090123/scribus/profiles/sRGB.icm \
-scribus-ng-1.3.5svn.dfsg~svn20090123/scribus/profiles/srgb.license \
-scribus-ng-1.3.5svn.dfsg~svn20090123/OSX-package \
-scribus-ng-1.3.5svn.dfsg~svn20090123/win32
+rm -r scribus/doc
+rm scribus/profiles/sRGB.icm
+rm scribus/profiles/srgb.license
+rm resources/swatches/*.eps
+rm resources/swatches/dtp-studio-free-palettes-license.rtf
+rm resources/swatches/GiveLife_Color_System_*.xml
+rm resources/swatches/givelife_colors_license.rtf
+rm resources/swatches/Federal_Identity_Program.xml
+rm -r OSX-package
+rm -r win32

 4. Create a tarball for package building:


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

Bug#735502: cppcheck: diff for NMU version 1.61+dfsg-0.1

[Vincent Cheng]

tag 735502 + patch
tag 735502 + pending
thanks

Dear Maintainer,

I've prepared an NMU for cppcheck (versioned as 1.61+dfsg-0.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I should
delay it longer.

The following debdiff consists of changes made to the package aside
from the removal of htdocs/*, which generates too much noise to be of
any use in this diff:

Regards,
Vincent

diff -Nru orig/cppcheck-1.61/debian/changelog
cppcheck-1.61+dfsg/debian/changelog
--- orig/cppcheck-1.61/debian/changelog 2013-08-04 01:04:20.0 -0700
+++ cppcheck-1.61+dfsg/debian/changelog 2014-05-12 11:37:45.0 -0700
@@ -1,3 +1,13 @@
+cppcheck (1.61+dfsg-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Octavio Alvarez ]
+  * Removed htdocs from source package to prevent licensing issues with
+sourceless JavaScript files. (Closes: #735502)
+
+ -- Gianfranco Costamagna costamagnagianfra...@yahoo.it  Fri, 09
May 2014 16:22:26 +0200
+
 cppcheck (1.61-1) unstable; urgency=low

   * New upstream release
diff -Nru orig/cppcheck-1.61/debian/copyright
cppcheck-1.61+dfsg/debian/copyright
--- orig/cppcheck-1.61/debian/copyright 2013-01-19 12:32:08.0 -0800
+++ cppcheck-1.61+dfsg/debian/copyright 2014-05-09 07:22:16.0 -0700
@@ -1,6 +1,7 @@
-Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=166
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: cppcheck
 Source: https://sourceforge.net/projects/cppcheck
+Files-Excluded: htdocs

 Files: *
 Copyright:
diff -Nru orig/cppcheck-1.61/debian/watch cppcheck-1.61+dfsg/debian/watch
--- orig/cppcheck-1.61/debian/watch 2011-02-06 10:20:48.0 -0800
+++ cppcheck-1.61+dfsg/debian/watch 2014-05-09 07:22:23.0 -0700
@@ -1,2 +1,2 @@
 version=3
-http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz
+opts=dversionmangle=s/\+dfsg// http://sf.net/cppcheck/cppcheck-(.+)\.tar\.gz


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

Bug#715278: intel-gpu-tools: Couldn't map MMIO region: Resource temporarily unavailable on intel_reg_read, after dist-upgrade

[Vincent Cheng]

Hi,

I'd be glad to update and maintain intel-gpu-tools within the pkg-xorg
team, however I'm having a bit of trouble pushing to the git repo
right now...

remote: fatal: Unable to create temporary file
'/srv/git.debian.org/git/pkg-xorg/app/intel-gpu-tools.git/./objects/pack/tmp_pack_XX':
Permission denied
error: unpack failed: index-pack abnormal exit
To git+ssh://git.debian.org/git/pkg-xorg/app/intel-gpu-tools.git
 ! [remote rejected] upstream-unstable - upstream-unstable (unpacker error)
error: failed to push some refs to
'git+ssh://git.debian.org/git/pkg-xorg/app/intel-gpu-tools.git'

Does anyone know what's going on?

Regards,
Vincent


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

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Vincent Cheng]

On Thu, May 8, 2014 at 1:13 AM, Fabian Greffrath fab...@greffrath.com wrote:
 Am Montag, den 05.05.2014, 23:15 -0700 schrieb Vincent Cheng:
 Don't forget that the Debian Games team
 has a sponsorship queue [1] that you can use if you're looking for a
 sponsor within the team; I aim to regularly check the queue for
 packages to sponsor.

 Alright, I have added my pending uploads there.

Built, signed, and uploaded, thanks for your work!

Please take the time to take a look at some of the issues that lintian
flags against your packages, and fix them next time. Some of the
issues are really simple and quick to fix (e.g. out of date Standards
version, missing patch headers, etc.), and doomsday in particular has
a number of d/copyright / DEP-5 related issues that should be fixed.

Regards,
Vincent


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

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Vincent Cheng]

On Mon, May 5, 2014 at 1:44 AM, Fabian Greffrath fab...@greffrath.com wrote:
 Dear Andreas,

 this bug is fixed in GIT since the day you reported it. However,
 unfortunately my regular sponsor is short of time and has somwhow thrown
 the towel for package uploads in the short term. Since I don't want to
 keep this (otherwise perfectly fine) package from testing any longer and
 since you reported that bug, would you mind sponsoring the upload?

 The package can be found here, it builds with git-buildpackage:
 http://anonscm.debian.org/gitweb/?p=pkg-games/chocolate-doom.git

Built, signed, and uploaded. Don't forget that the Debian Games team
has a sponsorship queue [1] that you can use if you're looking for a
sponsor within the team; I aim to regularly check the queue for
packages to sponsor.

Regards,
Vincent

[1] https://wiki.debian.org/Games/Sponsors/Queue


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

Bug#746251: catfish: /usr/bin/catfish fails to run - no such job error

[Vincent Cheng]

Hi Jackson,

 Dear Maintainer,

 After the last Stable update /usr/bin/catfish fails to run with a no
 such job error.

 bash: fg: %python%: no such job

 Changing the contents in /usr/bin/catfish from

 #!/usr/bin/env bash
 %python% /usr/share/catfish/bin/catfish.py $@

 to

 #!/usr/bin/env bash
 python /usr/share/catfish/catfish.py $@

 Fixes the error.

Do you intend on fixing to fix this bug soon-ish or not? I've tried
pinging you on IRC with no success, and I intend on NMU-ing this if
you still don't respond.

Regards,
Vincent


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

Bug#746251: catfish: /usr/bin/catfish fails to run - no such job error

[Vincent Cheng]

On Sun, May 4, 2014 at 11:44 PM, Jackson Doak nosk...@ubuntu.com wrote:
 Please nmu/team-upload this.
 I have not had access to a linux pc for around a month and won't have one
 for a few more weeks.

Thanks for the quick reply.

 I have forwarded this to the upstream developer so he sees the fix

It's irrelevant for upstream; this was a bug that you introduced when
you patched catfish in Debian wheezy to fix the various CVEs that
affected it. I'm sorry for not catching it when I sponsored your
package (really, I'm not sure how I missed this when I skimmed the
debdiff), but nevertheless, please please please actually _test_ your
package on a wheezy system next time before asking me to sponsor an
upload for wheezy.

Regards,
Vincent


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

Bug#744699: Frets On Fire bug report 744699

[Vincent Cheng]

Hi Gianfranco,

On Thu, Apr 17, 2014 at 11:06 PM, costamagnagianfra...@yahoo.it
costamagnagianfra...@yahoo.it wrote:
 Hi Paul and all,
 (sorry for the top posting, my android mail client allows only this mode)

 are you aware that at some point almost _every_ debian packages will be
 repackaged?

 I'm talking about embedded jquery as example and sdlgfx.
 What we do is symlink and remove jquery while building, but this leave the
 js in the source tarball.

 should we really remove and repackage almost every program that has a Docs
 folder?

 I think the point of having a binary file (not built by debian builders) in
 the binary package is a security issue, but removing and symlinking it while
 building isn't.

 And users installs only the binary, not the source.

 Following this rule we (or better you since I'm not a DD) will have to
 upload again some thousand packages just because of some js, some windows
 dll, some library leftover and so on.

 Unfortunately most upstream people don't care too much about this...
 should debian focus more on this rather than fixing bugs?

 (to clarify my position, I'm here to ask and learn, not to complain)

 Sorry for the (partial) off topic, I hope is ok with the list (I have also
 some (more) similar issues with games)

 Once you asked me to ask upstream to provide the _source_ file for every png
 file on the tarball and build it at runtime.

 Upstream said that they have not most of them anymore, that for 100MB of
 images they took DAYS in building.

 Should I repackage the 150MB source tarball with one 1500MB one, and move
 from 1 hour build to 1 week one?

 I honestly think that at some point we have to stop caring about all this
 stuff and focus more on bug fixes.

There's a lack of consensus about e.g. how to deal with jquery (refer
to that fairly long thread on debian-devel last month for some more
commentary [1]), and I think there was a thread here on
debian-devel-games that devolved into a similar discussion...so you'll
get a range of different opinions from DDs as to how to approach this,
ranging from the most strictest possible interpretation/application of
the DFSG to both binary and source packages vs. the bare minimum that
the ftpmasters would consider acceptable. Unless the ftpmasters decide
to explicitly spell out what's required and what's not, I don't think
the status quo will change.

If you think this situation is confusing and somewhat frustrating,
well, you're not the only one. :)

Regards,
Vincent

[1] https://lists.debian.org/debian-devel/2014/03/msg00190.html


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

Bug#728223: Bug#728220: Close too old and obsolete bugs

[Vincent Cheng]

reopen 728223
reopen 728224
reopen 728219
reopen 728217
reopen 728211
reopen 728212
thanks

On Tue, Apr 15, 2014 at 3:45 PM, Stéphane Aulery lk...@free.fr wrote:
 Upstream does not want to take care of these bugs as impacted versions
 are too old and it is not proven that they have been encountered in
 gnome 3.

Not a single one of these bugs are gnome-related bugs. Reopening.

Regards,
Vincent


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

Bug#744267: eggdrop: GPL + 4-clause BSD incompatibility

[Vincent Cheng]

Source: eggdrop
Version: 1.6.19-1
Severity: serious
Justification: Policy 2.3

Dear Maintainer,

src/compat/inet_aton.c contains code licensed under the 4-clause BSD license,
which includes the advertising clause:

 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *  This product includes software developed by the University of
 *  California, Berkeley and its contributors.

This is incompatible with the GPL [1][2], which is what most of eggdrop's
source is licensed under, making this undistributable by Debian as-is.

Regards,
Vincent

[1] http://www.gnu.org/licenses/license-list.html#OriginalBSD
[2] http://www.gnu.org/philosophy/bsd.html

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

Kernel: Linux 3.13-5-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


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

Bug#743685: FTBFS: test failures

[Vincent Cheng]

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

Dear Maintainer,

urwid 1.2.1-1 currently FTBFS on i386 and mipsel according to the buildd [1]
logs. Note that the test suite is now run against all python2 and python3
versions supported in sid (rather than just python2, as was the case with
previous versions of urwid); the test failure on i386 is a new one, and only
happens with python3.


i386 [2]:

==
FAIL: test_linefeed (urwid.tests.test_vterm.TermTest)
--
Traceback (most recent call last):
  File /«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py, 
line 128, in test_linefeed
self.expect('hello\nworld')
  File /«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py, 
line 120, in expect
self.assertEqual(got, what, desc)
AssertionError: b'hello' != b'hello\nworld' : Expected:
b'hello\nworld'
Got:
b'hello'

--
Ran 280 tests in 0.758s

FAILED (failures=1)


mipsel [3]:

==
FAIL: test_run (urwid.tests.test_event_loops.TwistedEventLoopTest)
--
Traceback (most recent call last):
  File /«PKGBUILDDIR»/urwid/tests/test_event_loops.py, line 128, in test_run
self.assertIn(da, out)
AssertionError: 'da' not found in ['waiting', 'hello', 'clean exit']

--
Ran 289 tests in 6.329s

FAILED (failures=1)


[1] https://buildd.debian.org/status/package.php?p=urwid
[2] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=i386ver=1.2.1-1stamp=1396632579
[3] 
https://buildd.debian.org/status/fetch.php?pkg=urwidarch=mipselver=1.2.1-1stamp=1396648217

Regards,
Vincent

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

Kernel: Linux 3.13-5-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


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

Bug#743118: [Python-modules-team] Bug#743118: urwid: FTBFS: Tests failures

[Vincent Cheng]

On Fri, Apr 4, 2014 at 9:00 AM, Ian Ward i...@excess.org wrote:
 On Mon, Mar 31, 2014 at 2:28 AM, Vincent Cheng vch...@debian.org wrote:
 I didn't come across this test failure when I built and uploaded urwid
 on my amd64 laptop, but the mips and sparc buildds are also choking on
 the same test case according to the build logs [1]; it's also
 preventing the package from migrating to testing. An upload to
 fix/skip this test would certainly be appreciated.

 Just released 1.2.1 with a fix

Uploaded, thanks!

Regards,
Vincent


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