Bug#775981: nvidia-graphics-drivers: nVidia bin drivers - Blank screen after install (EE: No screens found)

[Vincent Cheng]

Control: found -1 340.65-1
Control: notfound -1 340.65

Hi Borislav,

On Thu, Jan 22, 2015 at 1:27 AM, Borislav Sabev  wrote:
> Source: nvidia-graphics-drivers
> Version: 340.65
> Severity: important
>
> After trying to install the nVidia binary driver (340.65) from the Debian
> repositories (or even the installable package from the nVidia web site).
> The graphics card is nVidia NVS 5200M.
>
> uname -a:
> Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux
>
> Install goes OK - apt-get install logs:
> http://pastebin.com/86zZPbQn
>
> Install suggests reboot to enable the driver.
> I ran 'nvidia-xconfig' just before so I have a good xorg.conf.
> NOTE that even deleting the xorg.conf will not startx.
>
> The nvidia-xconfig generated xorg.conf:
> http://pastebin.com/jgnXTggt (seems totally fine)
>
> After reboot Xorg won't start. Error in Xorg.log is: "[6.102] (EE) no screens
> found(EE)"
> Full Xorg.0.log:
> http://pastebin.com/3kVwLxAZ
>
> /var/log/nvidia-installer.log:
> http://pastebin.com/aWyi9DSv (seems totally fine)
>
> System will default to the nouveau driver and I have graphics but from the
> Intel HD graphics. I cannot run the
>
> lspci | grep -i vga:
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] 
> (rev
> a1)

That sounds like you have an Nvidia Optimus-enabled system. Unless you
are able to disable your intel or nvidia gpu via a BIOS setting,
you'll have both your intel and nvidia gpu enabled, but your intel gpu
will be the one driving your main display, not nvidia. Installing the
proprietary driver (with no additional configuration) will not change
this (and a nvidia-xconfig generated xorg.conf would be broken for
you).

Your options include:
- just using your intel gpu and forgetting about your nvidia card
because optimus is still kind of a mess on linux
- installing and using bumblebee [1] - perhaps the easiest because
Debian has bumblebee packages
- sticking with nouveau and using PRIME [2]
- using nvidia-prime [3]

Regards,
Vincent

[1] https://wiki.debian.org/Bumblebee
[2] http://nouveau.freedesktop.org/wiki/Optimus/
[3] 
http://http.download.nvidia.com/XFree86/Linux-x86_64/340.32/README/randr14.html


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

Bug#776105: weechat: New upstream release (1.1)

[Vincent Cheng]

Package: weechat
Version: 1.0.1-1
Severity: wishlist

Dear maintainer,

Please consider packaging the latest upstream release (version 1.1). Thanks!

Regards,
Vincent


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

Bug#776598: bumblebee-nvidia: Cannot access secondary GPU - error: X did not start properly

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi,

On Thu, Jan 29, 2015 at 12:18 PM, solitone  wrote:
> Package: bumblebee-nvidia
> Version: 3.2.1-4~bpo70+1
> Severity: important
>
> Dear Maintainer,
>
> I have bumblebee-nvidia 3.2.1-4~bpo7 and nvidia-driver 340.65-2~bpo on
> an amd64 architecture laptop. My kernel version is:
>
> $ uname -a
> Linux aldous 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt2-1~bpo70+1 
> (2014-12-08) x86_64 GNU/Linux
>
> After all packages were succesfully installed, I tried and ran:
>
> $ optirun glxspheres64
>
> to test whether everything worked fine. I got this error message though:
>
> [ERROR]Cannot access secondary GPU - error: Could not load GPU driver
>
> I then edited /etc/bumblebee/bumblebeehihi.conf, and changed 
> "KernelDriver=nvidia"
> to "KernelDriver=nvidia-current", then restarted the bumblebee daemon.
>
> I retried the test with optirun, but this time I got a different error 
> message:
>
> [18100.861997] [ERROR]Cannot access secondary GPU - error: X did not start 
> properly
> [18100.862071] [ERROR]Aborting because fallback start is disabled.

Please attach your /var/log/Xorg.8.log.

Regards,
Vincent


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

Bug#773982: 0ad: Numerous error messages.

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

Hi John,

On Fri, Dec 26, 2014 at 9:25 AM, John Moyer  wrote:
> Package: 0ad
> Version: 0.0.17-1~bpo70+1
> Severity: normal
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> Normal play
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> Error messages:
>
> sys_cursor_create: using Xcursor to create 32 x 32 cursor
> TIMER| common/modern/setup.xml: 508.504 us
> TIMER| common/modern/styles.xml: 587.24 us
> TIMER| common/modern/sprites.xml: 3.52248 ms
> TIMER| common/setup.xml: 525.258 us
> TIMER| common/sprite1.xml: 1.37905 ms
> TIMER| common/styles.xml: 26.053 us
> TIMER| common/common_sprites.xml: 1.64601 ms
> TIMER| common/common_styles.xml: 217.125 us
> TIMER| savedgames/save.xml: 1.5928 ms
> TIMER| GetSavedGames: 58.1238 ms
> TIMER| common/modern/setup.xml: 148.139 us
> TIMER| common/modern/styles.xml: 156.173 us
> TIMER| common/modern/sprites.xml: 1.63737 ms
> TIMER| common/setup.xml: 470.623 us
> TIMER| common/sprite1.xml: 1.36875 ms
> TIMER| common/styles.xml: 22.66 us
> TIMER| common/common_sprites.xml: 1.64356 ms
> TIMER| common/common_styles.xml: 188.496 us
> TIMER| msgbox/msgbox.xml: 1.16223 ms
> ERROR: Script message handler OnGlobalConstructionFinished failed
> ERROR: Error in timer on entity 15128, IID 85, function TimerHandler: 
> InternalError: too much recursion
>   FSM.prototype.ProcessMessage@simulation/helpers/FSM.js:274
>   UnitAI.prototype.FinishOrder@simulation/components/UnitAI.js:3483
>   
> UnitAI.prototype.UnitFsmSpec.INDIVIDUAL.REPAIR.ConstructionFinished@simulation/components/UnitAI.js:2673
>   FSM.prototype.ProcessMessage@simulation/helpers/FSM.js:274
>   
> UnitAI.prototype.OnGlobalConstructionFinished@simulation/components/UnitAI.js:3827
>   
> UnitAI.prototype.UnitFsmSpec.INDIVIDUAL.REPAIR.REPAIRING.enter@simulation/components/UnitAI.js:2615
>   FSM.prototype.SwitchToNextState@simulation/helpers/FSM.js:376
>   FSM.prototype.ProcessMessage@simulation/helpers/FSM.js:284
>   UnitAI.prototype.FinishOrder@simulation/components/UnitAI.js:3483
>   
> UnitAI.prototype.UnitFsmSpec.INDIVIDUAL.REPAIR.ConstructionFinished@simulation/components/UnitAI.js:2673
>   FSM.prototype.ProcessMessage@simulation/helpers/FSM.js:274
>   
> UnitAI.prototype.OnGlobalConstructionFinished@simulation/components/UnitAI.j...
> Error printfing console message (buffer size exceeded?)

I can't reproduce these error messages locally when running 0ad.

Please file an upstream bug report at [1] and reply to the BTS with
the upstream URL so that we can track it here.

Regards,
Vincent

[1] http://trac.wildfiregames.com/newticket


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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#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  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=jessie&merged=ign&keypackages=ign&fnewerval=7&flastmodval=7&rc=1&chints=1&cdeferred=1&crttags=1&sortby=id&sorto=asc&format=html#results


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

Bug#773378: RFS: ledgersmb/1.3.46-1

[Vincent Cheng]

Control: tag -1 moreinfo

Hi Robert,

On Wed, Dec 17, 2014 at 8:54 AM, Robert James Clay  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "ledgersmb"
>
> * Package name: ledgersmb
>   Version : 1.3.46-1
>   Upstream Author :  Chris Travers 
> * URL : http://www.ledgersmb.org
> * License : GPL-2+
>   Section : web
>
> It builds those binary packages:
>
> ledgersmb  - financial accounting and ERP program
>
> To access further information about this package, please visit the following
> URL:
>
>   http://mentors.debian.net/package/ledgersmb
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/l/ledgersmb/ledgersmb_1.3.46-1.dsc
>
>   More information about ledgersmb can be obtained from
> http://www.ledgersmb.org.
>
>   Changes since the last upload:
>
> * New upstream release. (Closes: #771822)
>   - Fixes 'Duplicate message' errors in locale/po/hu.po. (Closes: #752063)
> * Add texlive-xetex as a 'Suggests' in debian/control.
> * Add new Dutch debconf translation. (Closes: #767242)
> * Minor updates and corrections to debian/README.Debian.
> * Add libjs-prototype & libjs-scriptaculous to Build-Depends.
> * Correct a copyright email address in the debian/copyright file.
> * Set permissions on ledgersmb/bin/gl.pl correctly in debian/rules.
> * Add a note regarding texlive-xetex to the debian/README.Debian file.
> * Set Standards-Version to 3.9.6 in debian/control, no changes required.
> * The contrib_dir setting in 05_confdir.patch is only needed for Pg v9.1.
> * Remove the use of drop_statoverride function from the maintainer scripts.
> * Use dh-linktree for embedded libjs-prototype and libjs-libjs-scriptaculous
>   libraries.
> * Only include the overrides for the 'custom' empty directories in the
>   ledgersmb.lintian-overrides.

Just a few small questions/comments from skimming through the debdiff:

- You added a small dpkg-maintscript-helper snippet to
debian/ledgersmb.postrm, specifically checking if dpkg is new enough
to support mv_conffile before using it; what happens if dpkg isn't
sufficiently new enough to support that / is that something that
should just fail? You can simply add a Pre-Depends:
${misc:Pre-Depends} (which will add a pre-dependency on the
appropriate version of dpkg) if you want to use
dpkg-maintscript-helper and not have to worry about whether dpkg is
new enough (and avoid that "if dpkg-maintscript-helper supports
mv_conffile" logic).
- Why bump the version number in debian/NEWS when there isn't a new
entry, and nothing else in the file has changed aside from the
timestamp? That seems likely to just annoy apt-listchanges users.

Also, note that since Debian is in freeze right now, if you wish to
target unstable, any (RC) bugfix uploads that you wish to get into
jessie would then have to go through testing-proposed-updates (which
the release team apparently really doesn't like). Are you sure you're
ok with that?

Regards,
Vincent


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

Bug#754071: [Python-apps-team] Bug#754071: python-pelican : please include docuemnts or make python-pelican-doc package.

[Vincent Cheng]

Control: tag -1 + patch

On Fri, Jan 2, 2015 at 8:16 AM, Federico Ceratto
 wrote:
> Package: python-pelican
> Version: 3.5.0-1
> Followup-For: Bug #754071
>
> Hello Vincent and thank you for maintaining the package. Attached is a patch 
> to
> build the -doc package. I had to switch debian/watch to use the tarball from
> GitHub as the PyPI version has no documentation in it.
> Also I switched to dh_python to simplify the build, I hope you don't mind.

Thanks for the patch! I skimmed through it and it looks good to me,
except that you're missing a build-dep on dh-python (since you're now
using dh_python/pybuild).

I'll hold off on uploading this for now, since Debian is in freeze and
the upload requires that I use a different orig tarball (which won't
work with the same upstream version unless I mangle the version,
urgh). But I'll include this in my next pelican upload. :)

Regards,
Vincent


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

Bug#773378: RFS: ledgersmb/1.3.46-1

[Vincent Cheng]

Hi Robert,

On Sat, Jan 3, 2015 at 8:26 AM, Robert J. Clay  wrote:
> Hi Vincent!
>
> On Fri, Jan 2, 2015 at 6:18 AM, Vincent Cheng  wrote:
>> Control: tag -1 moreinfo
>>
>> Hi Robert,
>>
>> On Wed, Dec 17, 2014 at 8:54 AM, Robert James Clay  wrote:
>>> Package: sponsorship-requests
>>> Severity: normal
>>>
>>> Dear mentors,
>>>
>>>   I am looking for a sponsor for my package "ledgersmb"
>>>
>>> * Package name: ledgersmb
>>>   Version : 1.3.46-1
>>>   Upstream Author :  Chris Travers 
>>> * URL : http://www.ledgersmb.org
>>> * License : GPL-2+
>>>   Section : web
>>>
>>> It builds those binary packages:
>>>
>>> ledgersmb  - financial accounting and ERP program
>>>
>
>> Just a few small questions/comments from skimming through the debdiff:
>>
>> - You added a small dpkg-maintscript-helper snippet to
>> debian/ledgersmb.postrm, specifically checking if dpkg is new enough
>> to support mv_conffile before using it; what happens if dpkg isn't
>> sufficiently new enough to support that / is that something that
>> should just fail?
>> You can simply add a Pre-Depends:
>> ${misc:Pre-Depends} (which will add a pre-dependency on the
>> appropriate version of dpkg)
>
>   That would do that simply because that form of it (mv_conffile) is
> used in the mantainer scripts?

Yes.

>> if you want to use
>> dpkg-maintscript-helper and not have to worry about whether dpkg is
>> new enough (and avoid that "if dpkg-maintscript-helper supports
>> mv_conffile" logic).
>
>  That version doesn't quite go back far enough for where I may want to
> support the package.  Although it's getting less likely to be an issue
> over time.  I'll admit I haven't needed to help with support on
> squeeze or lucid recently;   are you thinking that I'm worrying too
> much about a situation that isn't very likely and that would need to
> be supported differently in any case? (For instance, a separate
> backport for it, if necessary.)

I suggest one of three different options (preferably options 2 or 3,
whichever is most appropriate):

1) check if dpkg-maintscript-helper supports mv_conffile and then use
that, otherwise fallback to handwritten logic to rename the conffile
(see [1], or look at how dpkg-maintscript-helper itself is
implemented)
2) pre-depend on a sufficiently recent version of dpkg such that
mv_conffile is always known to be supported
3) don't rename the conffile at all (if it's not necessary)

My concern is that what you're currently doing seems to be a mix of
options 1 and 3, which is possibly worse than any of them, since the
outcome of running your maintainer scripts will differ depending on
what version of dpkg the user already has installed. You either always
want the conffile to be renamed, or you never want the conffile
renamed; I can't think of a valid scenario where you want to rename a
conffile if and only if dpkg supports renaming that conffile.

>> - Why bump the version number in debian/NEWS when there isn't a new
>> entry, and nothing else in the file has changed aside from the
>> timestamp? That seems likely to just annoy apt-listchanges users.
>
>To ensure that it is taken as being current and will be seen again
> as necessary.  (I've corresponded  with people who didn't look at it
> until I pointed it out that the info was there.)

That seems like something that should go in a readme file, or a
low-priority debconf notice at most. debian/NEWS is essentially meant
to be a more visible user changelog that's used to notify the user of
significant changes [2], not a recurring, identical message that is
displayed every time the user updates this package. That being said,
there's nothing in Policy that prevents maintainers from (ab)using
debian/NEWS for different purposes, so I guess ultimately it's up to
you as maintainer.

Also, AFAIK apt-listchanges isn't installed by default on Debian, so
users aren't guaranteed to see your NEWS entry anyways.

>> Also, note that since Debian is in freeze right now, if you wish to
>> target unstable, any (RC) bugfix uploads that you wish to get into
>> jessie would then have to go through testing-proposed-updates (which
>> the release team apparently really doesn't like). Are you sure you're
>> ok with that?
>
> None of the three bugs I'm seeking to close with this upload are RC,
> so I had not anticipated being able to update the package in jessie in
> any case.   (The new package upgrade I'm working on now involves an
> upgrade from v1.3.x to v1.4.x;  this upgrade for 1.3.46 is currently
> the last in the 1.3.46 series.)

Ok, sounds fine to me then (please address the
maintscript/conffile-renaming issue though).

Regards,
Vincent

[1] https://wiki.debian.org/DpkgConffileHandling
[2] 
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian


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

Bug#770149: RFS: python-instagram/1.2.0-1 [ITP]

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Jörg,

On Wed, Nov 19, 2014 at 12:08 AM, Jörg Frings-Fürst
 wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
>
> Dear mentors,
>
>   I am looking for a sponsor for my package "python-instagram"
>
>Package name: python-instagram
>Version : 1.2.0-1
>Upstream Author : Instagram, Inc 
>URL : http://github.com/Instagram/python-instagram
>License : BSD-3
>Section : python
>
>   It builds those binary packages:
>
> python-instagram - Python 2 client for the Instagram REST and Search APIs
> python3-instagram - Python 3 client for the Instagram REST and Search APIs
>
>   To access further information about this package, please visit the 
> following URL:
>
>   http://mentors.debian.net/package/python-instagram
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/p/python-instagram/python-instagram_1.2.0-1.dsc
>
>   Changes since the last upload:
>
>
>   * Initial release (Closes: #769928).

Here's a quick review (this is in addtion to the other reviews that
have already been done on python-instagram):

- X-Python-Version and X-Python3-Version belong in the source stanza
in d/control, not in the binary packages stanzas
- instead of having an empty watch file, you can point it to PyPI
instead, i.e. https://pypi.python.org/pypi/python-instagram
- there's been a new upstream release that you may want to consider packaging

Team-maintaining this package in the DPMT and using a more permissive
license for debian/* were both already mentioned in earlier reviews as
well.

Regards,
Vincent


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

Bug#769673: RFS: lletters/0.1.95+gtk2-4 [ITA, RC]

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Dmitry,

On Sat, Nov 15, 2014 at 6:10 AM, Dmitry Borisyuk  wrote:
> Package: sponsorship-requests
> Severity: important
>
>   Dear mentors,
>
>   I am looking for a sponsor for the package "lletters"
>
>  * Package name: lletters
>Version : 0.1.95+gtk2-4
>  * URL : http://lln.sourceforge.net/
>  * License : GPL-2
>Section : games
>
>   It builds those binary packages:
>
> lletters   - Linux Letters and Numbers - learning game for small children
>
>   To access further information about this package, please visit the 
> following URL:
>
>   http://mentors.debian.net/package/lletters
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/l/lletters/lletters_0.1.95+gtk2-4.dsc
>
>   Changes since the last upload:
>
>   * New maintainer (Closes: #755283).
>   * Source converted to format 3.0 (quilt).
>   * gettext infrastructure updated, which fixes FTBFS (Closes: #749360).
>   * Use dh-autoreconf to update autotools scripts during build, thanks
>  Matthias Klose  (Closes: #538667, #727450).
>   * Fixed reading .wav files on 64-bit architectures (Closes: #701852).
>   * Don't terminate if cannot open /dev/dsp, just disable sound instead 
> (Closes: #712845).
>   * Improved LANG variable handling, thanks Prathibha B .
>   * Manpage supplemented with FILES and ENVIRONMENT sections.
>   * Configuration file (llnrc) rewritten (Closes: #703384).
>   * Standards-Version bumped to 3.9.6

This is just a very brief review:

Can you also adopt lletters-media at the same time? That package is
orphaned and is a dependency of lletters. Would you consider
team-maintaining this package in the Debian Games team [1] as well?
You'll generally find it easier to find sponsors within a team.

I'm mostly concerned about the size of some of your patches in
debian/patches; it makes your package hard to review, and they're
probably obsolete as well (e.g. what's the purpose of
debian/patches/debian-changes-0.1.95+gtk2-3.2.patch when you're
running autoreconf during the build?).

While reviewing lletters, I discovered that Markus put together a
minimal, easy-to-review debdiff to fix various bugs in lletters in
#749360, so I'll go ahead and upload that first (just so we can get
some RC bugs fixed and out of our way, and so you can focus on the
packaging bits that you'd like to change). Hope that helps!

Regards,
Vincent

[1] https://wiki.debian.org/Games/Team


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

Bug#771433: RFS: xastir/2.0.6-1

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Iain,

On Sat, Nov 29, 2014 at 6:53 AM, Iain R. Learmonth  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "xastir"
>
>  * Package name: xastir
>  Version : 2.0.6-1
>  * URL : http://xastir.org/
>  * License : GPL-2
>  Section : hamradio
>
> It builds those binary packages:
>
>   xastir - X Amateur Station Tracking and Information Reporting
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/xastir
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> http://mentors.debian.net/debian/pool/main/x/xastir/xastir_2.0.6-1.dsc
>
> Changes since the last upload:
>
>   * Update to new upstream version (Closes: #761837)
>   * Update to 3.9.6 packaging standard.
>   * Changed priority to optional.
>   * Corrected Maintainer: line in control file.
>   * Removed uploaders inactive on the package.
>   * Package source now maintained in Hamradio Maintainers' git VCS.
>

Here's a quick review of your package:

Were the uploaders that you removed from d/control asked to be removed
by the MIA team, or declare publicly (e.g. on a bug or mailing list)
that they wish to be removed? If not, please don't unilaterally remove
people from uploaders; go through the MIA process [1] and have the MIA
team ensure that the uploaders in question are indeed inactive before
removing them.

A number of issues with debian/copyright:
- GPL version not specified
- copyright owners+dates not specified
- "2) Some of the programs in the scripts directory may contain other
licensing information.  See the individual files for details."
wouldn't pass ftpmaster scrutiny

You may want to consider updating d/copyright to use DEP-5 while
you're fixing the above issues.

Regards,
Vincent

[1] https://wiki.debian.org/Teams/MIA


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

Bug#771928: nvidia-driver: Inconsistencies between the Nvidia installer and nvidia-driver on Optimus notebook

[Vincent Cheng]

Hi Tomaz,

Bumblebee maintainer and nvidia-driver co-maintainer here (although to
be fair w.r.t. nvidia-driver, Andreas does most of the work there :P
); sorry for the late reply!

On Wed, Dec 3, 2014 at 7:49 AM, Tomaz Fogaça  wrote:
> Package: nvidia-driver
> Version: 340.46-5
> Severity: important
>
> Dear Maintainer,
>
> I've struck some inconsistencies between the nvidia-driver package and the
> Nvidia installer provided by Nvidia themselves, through their site.

To the best of my understanding, what you're seeing (and I'll
elaborate further below with inline replies to the other parts of your
bug report) are probably not inconsistencies, but different methods of
enabling Optimus functionality on Linux, admittedly none of which are
seamless as with Windows. Arch Linux's wiki article on Optimus [1]
describes the current options pretty well (I suggest at least reading
the summary), i.e.

1) nouveau-only: PRIME GPU offloading using nouveau [2]
2) nvidia-only: nvidia's more recent implementation [3], also packaged
as nvidia-prime [4] in Ubuntu
3) nouveau or nvidia: bumblebee

...all of which have their own benefits and drawbacks.

It's worth pointing out that in Debian, only option 3 is packaged (as
bumblebee, bbswitch, and primus); options 1 and 2 should be possible,
but involve manual configuration. There's a request for nvidia-prime
to be packaged in Debian [5], but I simply haven't had time to get
around to it. The package in Ubuntu does not seem to be readily
backport-able to Debian, unfortunately.

> Whenever I try installing the Nvidia drivers/libraries through the Nvidia
> installer, I get the expected results: the drivers are installed and the
> libraries are
> put into place so that when I have Xorg come up, all applications requiring
> OpenGL work as expected, and it would seem to me that either the Nvidia
> installer enables
> transparent GPU switching or it just sends all commands straight to the
> discrete GPU automatically.

That's probably nvidia-prime; I actually wasn't aware that the
nvidia's installer configures that automatically (but see [3] if you
want to do it yourself). I'll point out that this doesn't offer
transparent GPU switching; in order to switch between having your main
X display be driven by either your Intel or nvidia GPU, you need to
kill your current X session and start a new one. This also partially
defeats one of the supposed benefits of Optimus, i.e. that your nvidia
GPU is powered down when not in use to save battery life on your
laptop; with nvidia-prime, with your nvidia GPU enabled, it remains
enabled and powered on until you end your current X session, as
opposed to e.g. bumblebee.

> On the other hand, if I install the 'nvidia-driver' package, which installs
> with it the OpenGL, GLX
> and Xserver libs, and then use 'update-alternatives --config glx' to have
> glx point to the nvidia implementation, and then fire up xorg, I can't get
> my OpenGL
> programs to work. 'glxinfo' gives me errors like 'Xlib: extension "GLX"
> missing on display "0:0".
>
> If I use the alternatives system to have glx point instead to mesa-diverted,
> this results in using the integrated GPU for everything.

Yes, without any X server configuration (either done by yourself or
apparently by nvidia's installer), you'll be using your intel GPU to
drive your primary display, and that requires mesa's libGL
implementation rather than nvidia's. This is the ideal configuration
if you can disable your nvidia GPU via a BIOS setting and choose not
to use your nvidia GPU.

> I'm doing all of these experiments on a live system without persistency, so
> I can mess around with configs and reset them upon reboot. Also, I'm not
> using any
> Xorg.conf file.
>
> I eventually tried using bumblebee. I used 'update-alternatives --config
> glx' to make glx point to the mesa-diverted libs and indeed, I could get
> OpenGL working (
> with 'optirun someOpenGLApp' ). But it bugs me that the Nvidia installer can
> work some magic to switch GPUs automatically or to always use the Nvidia
> card, but I
> can't get that to work with the debian nvidia packages, and must always use
> bumblebee explicitly.

And of course bumblebee is also a viable option; this allows you to
run applications using your nvidia GPU on-demand, and bumblebee will
automatically toggle your nvidia GPU on and off as necessary (this is
actually done by bbswitch), but you have to specify which applications
you want using optirun (everything uses your Intel GPU by default).
Note that bumblebee may not offer the best performance compared to
nvidia-prime (it works essentially by intercepting GLX calls and
redirecting GL rendering to an invisible, secondary X display, then
copying everything back to the primary X display, from what I
understand).

In summary, there's no perfect solution, although it would be nice if
nvidia-prime was packaged for Debian...it's on my todo list, but I
totally wouldn't mind if someone beats me in packaging it for Debian.

Bug#756522: bumblebee-nvidia: cannot access secondary gpu - error: Permission denied

[Vincent Cheng]

Hi,

Sorry for the late reply!

On Wed, Nov 26, 2014 at 3:34 AM, theo  wrote:
> Package: bumblebee
> Version: 3.2.1-7
> Followup-For: Bug #756522
>
> Hello,
>
>
> I'm also affected by this bug.
[...]
> [  1536.440] (II) NOUVEAU driver Date:   Thu Aug 28 03:57:48 2014 +0200
> [  1536.440] (II) NOUVEAU driver for NVIDIA chipset families :
> [  1536.440]RIVA TNT(NV04)
> [  1536.440]RIVA TNT2   (NV05)
> [  1536.440]GeForce 256 (NV10)
> [  1536.440]GeForce 2   (NV11, NV15)
> [  1536.440]GeForce 4MX (NV17, NV18)
> [  1536.440]GeForce 3   (NV20)
> [  1536.440]GeForce 4Ti (NV25, NV28)
> [  1536.440]GeForce FX  (NV3x)
> [  1536.440]GeForce 6   (NV4x)
> [  1536.440]GeForce 7   (G7x)
> [  1536.440]GeForce 8   (G8x)
> [  1536.440]GeForce GTX 200 (NVA0)
> [  1536.440]GeForce GTX 400 (NVC0)
> [  1536.440] (--) using VT number 1
>
> [  1536.440] (EE) [drm] KMS not enabled
> [  1536.440] (EE) No devices detected.
> [  1536.440] (EE)
> Fatal server error:
> [  1536.440] (EE) no screens found(EE)
> [  1536.440] (EE)
> Please consult the The X.Org Foundation support
>  at http://wiki.x.org
>  for help.

First off, does your nvidia GPU fit into any of the above
nouveau-supported families? If it's a fairly recent nvidia GPU, it may
simply not be supported by nouveau, in which case you'll either have
to use the proprietary nvidia driver, or perhaps try upgrading to a
more recent kernel to see if nouveau now supports your GPU. The other
error message that concerns me in your X log is "[drm] KMS not
enabled"; did you somehow disable KMS (e.g. nomodeset,
nouveau.modeset=0 or similar on your grub command line)? If so, you'll
want to undo that.

Alternatively, if nouveau still does not detect your nvidia GPU, try
editing /etc/bumblebee/xorg.conf.nouveau and manually specify a BusID
in that file, then restart bumblebeed? (refer to the comments there
for a brief howto)

Regards,
Vincent


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

Bug#756522: bumblebee-nvidia: cannot access secondary gpu - error: Permission denied

[Vincent Cheng]

Hi Dirk,

Sorry for the late reply! Please do take care to cc the actual bug
report as well instead of directly replying only to me (there's a good
chance for stuff to just get lost in my inbox, unfortunately).

On Fri, Nov 21, 2014 at 2:14 PM, Dirk Linnerkamp
 wrote:

> Dear Maintainer,
>
> since I've the same issue with the same Debian-Jessie System and bumblebee I
> feel free  to answer your message and provide the additional Information you
> asked for.
>
> My "bumblebee", "xserver-xorg" and "xserver-common" versions are the same as
> in Mareks post which I answer.
>
> I've attached a file with all information you requested.

Next time please either reply inline or put everything into a text
file, not an OpenOffice/LibreOffice Writer document.

According to your /var/log/Xorg.8.log logfile, it looks like the
problem is that for some reason the nvidia driver is unable to detect
your nvidia GPU, i.e.

[ 9176.525] (II) NVIDIA dlloader X Driver 340.46 Wed Sep 24 13:34:03 PDT 2014
[ 9176.525] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[ 9176.525] (­­) using VT number 7
[ 9176.525] (EE) No devices detected.
[ 9176.525] (EE)
Fatal server error:
[ 9176.525] (EE) no screens found(EE)
[ 9176.525] (EE)
Please consult the The X.Org Foundation support
for help.
at http://wiki.x.org

Is your nvidia GPU supported by nvidia-driver 340.46? See supported
products section at [1]. Otherwise, you may have to set the BusID
manually in /etc/bumblebee/xorg.conf.nvidia. Refer to the comments in
that file for a brief howto.

Regards,
Vincent

[1] http://www.nvidia.com/download/driverresults.aspx/78469/en-us


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

Bug#756522: bumblebee-nvidia: cannot access secondary gpu - error: Permission denied

[Vincent Cheng]

On Sun, Jan 4, 2015 at 4:21 AM, Dirk Linnerkamp
 wrote:
[...]
> Meanwhile I found the solution which I posted on GitHub where I looked also
> for a solution. See the conversation here:
>
> https://github.com/Bumblebee-Project/Bumblebee/issues/580
>
> The solution (for me) was, that I had to DELETE the BusID parameter in my
> "/etc/bumblebee/xorg.conf.nvidia". I set this parameter at first manually,
> as you suggested. I checked twice if it was the correct number, but the
> error message remained.

Hmm, ok, good to know I suppose. By default the BusID parameter in
/etc/bumblebee/xorg.conf.{nouveau,nvidia} is commented out anyways,
and users should only fiddle with it if they can't get bumblebee
working as-is.

Regards,
Vincent


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

Bug#769673: RFS: lletters/0.1.95+gtk2-4 [ITA, RC]

[Vincent Cheng]

Hi Dmitry,

On Sun, Jan 4, 2015 at 7:38 PM, Dmitry Borisyuk  wrote:
> Dear Vincent,
>
> Thanks for your review.
>
> The purpose of debian/patches/debian-changes-0.1.95+gtk2-3.2.patch
> was to switch to source format 3.0 (quilt). It contains the changes
> between the upstream and Debian version 3.2. Many files were changed,
> not just autoconf-related ones, so I need this patch to incorporate those 
> changes.

I no longer have your package on hand, nor can I find it on
mentors.d.n, so I can't discuss any specifics, but IIRC that giant
patch shouldn't have been necessary if you were going to run
autoreconf at some point during the build.

> Why use 3.0 (quilt)? Beacuse some sponsors insist on it, so I thought it's 
> somewhat like mandatory... If you prefer source format 1.0, this patch is not 
> needed, of course.

I myself prefer 3.0 (quilt) as source format as well...the reason
being that it encourages maintainers to use a common workflow and also
encourages changes to the source code to be represented as a set of
self-contained, easily reviewable patches. However, it is still
possible to abuse 3.0 (quilt) and make patches difficult to review
simply by just providing a single giant patch (e.g. by making a bunch
of unrelated changes to the source package, then running dpkg-source
--commit). I'm not saying that's what you did, just wanted to
emphasize the fact that sponsors don't usually insist on something
just because it's mandatory (3.0 (quilt) is not mandatory, by the
way), but because it directly or indirectly leads to the package being
easier to review and maintain.

FWIW, my sponsoring approach usually involves reading the debdiff (to
the last upload), and the most off-putting thing for me to review is
something with a massive diff; I'm sure the release team can attest to
that as well.

> There are some other patches, which are not strictly needed, but I thought 
> they improve the package, I could explain in detail if you wish.

You're more than welcome to upload a new package to mentors.d.n if
you'd still like to adopt lletters, and we can go from there. :)

> Yes, I could adopt lletters-media if this is a precondition for adopting 
> lletters. I'm not familiar with what team-maintaining is,
> at a glance it seems that lletters is not well suited for Games team.

It's not mandatory for you to adopt lletters-media, but as it is a
dependency of lletters (and the two source packages come from the same
upstream anyways), I would strongly recommend doing so; e.g. if
lletters-media ever gets removed due to a RC bug, lletters will also
be removed, and the best way to prevent that is to adopt the former
package and ensure that never happens.

Team maintenance is up to you, but I generally encourage it as well
because it allows for a group of maintainers to collaborate together
on the same set of packages, and it's also easier for you to seek
sponsorship or just general help with your package if you're
co-maintaining a package or maintaining it in a team. Just curious,
why do you think lletters is not suitable for team maintenance under
the Games team?

Regards,
Vincent


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

Bug#750708: RFS: audiotools/2.21-3 [ITP] -- Collection of audio handling programs for the command line

[Vincent Cheng]

On Sun, Jan 4, 2015 at 9:46 PM, Eric Shattow  wrote:
> Updated at m.d.o although actually there is a new major version
> audiotools 3.0 updated for Python3 and I'm also working on this.

I get a different error this time; looks like yet another missing
build-dep. Please test build your package in a clean sid chroot (tools
like pbuilder make this really simple to do).

/usr/bin/make -C docs
make[2]: Entering directory '/tmp/buildd/audiotools-2.22+dfsg1/docs'
cd reference && make audioformats-letter.pdf
make[3]: Entering directory '/tmp/buildd/audiotools-2.22+dfsg1/docs/reference'
python simple-template.py -D PAPERSIZE=letterpaper
audioformats.template > audioformats-letter.tex
./bitdiagram.py -i figures/diagram.bdx -o figures/diagram.pdf
./bitdiagram.py -i figures/diagram2.bdx -o figures/diagram2.pdf
./bitparse.py -i figures/big_endian.bpx -o figures/big_endian.pdf
./bitparse.py -i figures/little_endian.bpx -o figures/little_endian.pdf
./bitparse.py -i figures/unary1.bpx -o figures/unary1.pdf
./bitdiagram.py -i figures/wav/stream.bdx -o figures/wav/stream.pdf
./bitdiagram.py -i figures/wav/fmt.bdx -o figures/wav/fmt.pdf
./bitdiagram.py -i figures/wav/fmtext.bdx -o figures/wav/fmtext.pdf
./bitdiagram.py -i figures/wav/data.bdx -o figures/wav/data.pdf
./bitdiagram.py -i figures/aiff/stream.bdx -o figures/aiff/stream.pdf
./bitdiagram.py -i figures/aiff/comm.bdx -o figures/aiff/comm.pdf
./bitdiagram.py -i figures/aiff/ssnd.bdx -o figures/aiff/ssnd.pdf
./bitdiagram.py -i figures/au_stream.bdx -o figures/au_stream.pdf
bison -d pseudocode-src/pseudocode.y -o pseudocode-src/pseudocode.tab.c
make[3]: bison: Command not found
Makefile:661: recipe for target 'pseudocode-src/pseudocode.tab.c' failed
make[3]: *** [pseudocode-src/pseudocode.tab.c] Error 127

Regards,
Vincent


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

Bug#750708: RFS: audiotools/2.21-3 [ITP] -- Collection of audio handling programs for the command line

[Vincent Cheng]

Hi Eric,

I took a look at your updated audiotools package (versioned 3.0-1) on
mentors.d.n. Your package still FTBFS in a clean sid chroot (looks
like due to a missing build-dep); again, please take a look at using
pbuilder/cowbuilder/sbuild or similar to test build your packages if
you aren't doing so already.

Also, if you're using pybuild (and you are), please declare an
explicit build-dep on dh-python.

cd reference && make audioformats-letter.pdf
[...]
fig2dev -Z 3.5 -L pdf flac/figures/lag0.fig flac/figures/lag0.pdf
sh: 1: gs: not found
Error in ghostcript command
command was: gs -q -dNOPAUSE -sAutoRotatePages=None
-dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode
-sDEVICE=pdfwrite -dPDFSETTINGS=/prepress
-sOutputFile=flac/figures/lag0.pdf - -c quit
Makefile:774: recipe for target 'flac/figures/lag0.pdf' failed
make[3]: *** [flac/figures/lag0.pdf] Error 255

Regards,
Vincent


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

Bug#774428: unblock: simpleburn/1.7.0-2

[Vincent Cheng]

On Tue, Jan 6, 2015 at 1:39 PM, John Paul Adrian Glaubitz
 wrote:

> On 01/06/2015 10:35 PM, Holger Levsen wrote:
>> well, yes, but then probably not really (in all cases) for scripts
>> which were explicitly written for bash...
>
> Alright, I guess we will have to go the t-p-u way then. Would it be
> ok if I prepared an upload of simpleburn_1.7.0-1+deb8u1 for t-p-u
> with the proposed change of the shebang?

Why not just upload simpleburn to sid with the proposed shebang
change, and revert the patch that was added in the latest upload as
well (since it's broken as Adam suggested)? The maintainer can always
deal with fixing the actual bashisms (ideally upstream as well) after
the freeze.

Regards,
Vincent


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

Bug#774740: nmu: chromaprint_1.1-1~bpo70+1

[Vincent Cheng]

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

Hi,

chromaprint (and hence VLC) is currently not installable in wheezy-backports
(reported on debian-backports [1]).

nmu chromaprint_1.1-1~bpo70+1 . ALL . wheezy-backports . -m "Rebuild due to 
libav ABI bump"

Regards,
Vincent

[1] https://lists.debian.org/debian-backports/2015/01/msg9.html

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

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


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

Bug#750708: RFS: audiotools/2.21-3 [ITP] -- Collection of audio handling programs for the command line

[Vincent Cheng]

Hi Eric,

I took a look again at your updated audiotools package (versioned
3.0-1) on mentors.d.n. Just a few comments:

Do you really need strict versions on *all* your build-deps and
dependencies? I'd strongly recommend only using versioned
deps/build-deps when necessary, otherwise e.g. you make it harder for
others to backport your package.

debian/patches is empty and can be removed

debian/copyright:
- src/bitstream{.c,.h,-table.c} are dual-licensed (LGPL-3+ or GPL-2+),
but not mentioned in d/copyright
- src/output/sfifo.{c,h} are licensed under LGPL-2.1, not 2.1+ as you
claim in d/copyright

...and some other d/copyright-related issues caught by lintian (as
well as a number of other info-priority tags you may want to look at):
I: audiotools source: wildcard-matches-nothing-in-dep5-copyright
src/decoders/dvd_css.c (paragraph at line 25)
I: audiotools source: wildcard-matches-nothing-in-dep5-copyright
src/decoders/dvd_css.h (paragraph at line 25)
I: audiotools source: wildcard-matches-nothing-in-dep5-copyright
src/decoders/csstables.h (paragraph at line 32)
I: audiotools source: wildcard-matches-nothing-in-dep5-copyright
src/decoders/ioctl.c (paragraph at line 36)
I: audiotools source: wildcard-matches-nothing-in-dep5-copyright
src/decoders/ioctl.h (paragraph at line 47)
I: audiotools source: unused-file-paragraph-in-dep5-copyright
paragraph at line 25
I: audiotools source: unused-file-paragraph-in-dep5-copyright
paragraph at line 32
I: audiotools source: unused-file-paragraph-in-dep5-copyright
paragraph at line 36
I: audiotools source: unused-file-paragraph-in-dep5-copyright
paragraph at line 47

Regards,
Vincent


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

Bug#748753: Upload xxv-intel 2.99.x to sid?

[Vincent Cheng]

Hi,

Now that jessie is out and the freeze is over, would anyone object if
I were to upload xserver-xorg-video-intel from experimental to sid
now? 3.0 is supposed to be an "imminent release" [1] anyways.

Regards,
Vincent

[1] http://lists.freedesktop.org/archives/intel-gfx/2014-December/057900.html


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

Bug#748753: Upload xxv-intel 2.99.x to sid?

[Vincent Cheng]

On Tue, Apr 28, 2015 at 9:57 AM, Emilio Pozuelo Monfort
 wrote:
> On 28/04/15 12:02, Vincent Cheng wrote:
>> Hi,
>>
>> Now that jessie is out and the freeze is over, would anyone object if
>> I were to upload xserver-xorg-video-intel from experimental to sid
>> now? 3.0 is supposed to be an "imminent release" [1] anyways.
>
> Given that 2.21.x is completely unmaintained, and that the only relevant 
> changes
> from 2.21.15 to 2.99.901 [1] were SNA enabled by default (which upstream
> considers ready and which can be reverted anyway) and XMir integration (which 
> we
> don't care about) I see no reason to withhold this upload any longer. It's not
> like we're going to release Stretch with 2.21.x again, so the sooner we upload
> it, the more testing it will get. FWIW I used it for several months without 
> issues.
>
> This sounds similar to Grub2 being at 2.02~beta2, or when it was at 1.99 for 
> so
> long.

Fully agreed here. I've also given out my rationale for updating to
2.99.x in an earlier mail to #748753 [1].

Upstream clearly doesn't particularly care about sane versioning; I
don't think it's helpful to get hung up on the versioning scheme and
the lack of a formal release here.

Regards,
Vincent

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


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

Bug#783677: RM: wesnoth-1.10 -- ROM; obsolete, replaced with wesnoth-1.12

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove wesnoth-1.10 from the archive. It has been superseded by the
wesnoth-1.12 package.

Regards,
Vincent


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

Bug#750708: RFS: audiotools/2.21-3 [ITP] -- Collection of audio handling programs for the command line

[Vincent Cheng]

Hi Eric,

First off, sorry (again) for the prolonged delay!

On Mon, Jan 19, 2015 at 5:12 PM, Eric Shattow  wrote:
> Reviewed copyright info and trying again (Uploaded: 2015-01-20 00:14)
> http://mentors.debian.net/debian/pool/main/a/audiotools/audiotools_3.0-1.dsc
>
> All references to DeCSS were removed for 3.0 major release so I
> refreshed d/copyright. Tested in pbuilder.

One more copyright entry missing in d/copyright, then I think we're
ready for an upload:

audiotools/ply/*: Copyright 2001-2011 David M. Beazley, 3-clause BSD

Regards,
Vincent


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

Bug#756522: Cannot access secondary GPU - error: [XORG] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

[Vincent Cheng]

Hi Xavi,

On Sat, Mar 14, 2015 at 9:00 AM, Xavi Llistes  wrote:
> Hi there,
> same problem for me wiht fresh install.
>
> -- System Information
> Debian Release: jessie
> Architecture: amd64 (x86_64)
> Installer: debian Installer RC1
> $ uname -a
> Linux machine 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64
> GNU/Linux
>
> -- Packages version
> Bumblebee: 3.2.1-7
> Bumblebee-nvidia: 3.2.1-7
> Primus: 0~20140711-1
> xserver-xorg-video-nouveau: 1:1.0.11-1
> xserver-xorg-video-nvidia: 340.65-2
> libgl1-nvidia-glx-i386:i386: 340.65-2
> libgl1-nvidia-glx-i386: 340.65-2
> bbswitch-dkms: 0.8-1
> libvdpau1: 0.8-3
> libxnvctrl0: 340.65-2
> nvidia-installer-cleanup: 20141201+1
>
> -- Graphics
> Using Intel HD 4600 and Nvidia GTX 960M with i7 4712MQ.

I don't think the current nvidia driver in either sid or experimental
supports that card (and I'd bet that nouveau doesn't either). Probably
not a bumblebee issue, just a matter of waiting until the latest
nvidia driver gets packaged. Sorry for the delay!

Regards,
Vincent


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

Bug#756522: bumblebee-nvidia: cannot access secondary gpu - error: Permission denied

[Vincent Cheng]

Hi,

On Wed, Apr 22, 2015 at 6:48 AM, JEBE  wrote:
> Package: bumblebee
> Version: 3.2.1-7
> Followup-For: Bug #756522
>
> Dear Maintainer,
>
> I installed bumblebee and primus packages, not bumblebee-nvidia. But I get the
> exact same issues and logs than described here.
[...]
> My bumblebee.conf has the line "driver= ". I understand that only
> "xorg.conf.nouveau" is active. Is that correct?

Yes, if you only have either nvidia or nouveau installed, not both,
bumblebee will detect that (if you have both installed, bumblebee will
default to nvidia).

[...]
> [  6143.889] (EE) [drm] KMS not enabled
> [  6143.889] (EE) No devices detected.

Hmm...do you have nomodeset or nouveau.modeset=0 specified somewhere
(e.g. on your grub command line)? Is your GPU supported by nouveau?

Regards,
Vincent


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

Bug#782097: nvidia-kernel-dkms: Pixelised wallpaper while leaving Suspend with NVIDIA Driver

[Vincent Cheng]

Hi,

On Tue, Apr 7, 2015 at 1:31 PM, Webmailadress1  wrote:
> Package: nvidia-kernel-dkms
> Version: 340.65-2
> Severity: normal
>
> Dear Maintainer,
>
> I'm currently using Jessie and Gnome Shell and have installed the last 
> version of NVIDIA driver as explained here :
> https://wiki.debian.org/NvidiaGraphicsDrivers#jessie
> The problem occurs when my computer is suspended and I hit a key to "wake it 
> up". The lock screen is
> pixelized, but then I can hit Enter to got a regular password prompt to 
> unlock my session. When my session opens,
> I recover the usual Gnome Shell interface, except the wallpaper, which is 
> once again pixelized. I found two
> solutions to solve the problem, but both must be repeated each time I suspend 
> my computer :
>   * Change wallpaper (by right-clicking on the desktop), or
>   * Restart Gnome Shell (by Alt+F2, then typing "r" and Enter)
> It's particularly annoying to do that each time I wake my computer up!
> Several forums members seem to have the same problem as I, for example here 
> (in french) :
> http://forums.fedora-fr.org/viewtopic.php?id=63332

This sounds like #765436. Merging accordingly, thanks for the bug report.

Regards,
Vincent


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

Bug#781355: [Python-modules-team] Bug#781355: python-docker: New upstream version

[Vincent Cheng]

On Tue, Mar 31, 2015 at 11:41 AM, Tianon Gravi  wrote:

> The first is that I don't know the "proper" branch format for
> experimental in debian-python's SVN tree (it looks like it's just keep
> going forward in trunk and create a branch when/if a new sid/jessie
> upload is required, but I can't find any documentation to confirm or
> deny that).

I'm unsure myself if there's supposed to be some kind of convention
for branching for different releases; I usually track sid in trunk and
have a separate directory in branches for experimental or backports
branches, etc. Whatever works for you, I suppose.

Of course, this will all be moot once (if?) we migrate from svn to git, right?

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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  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
> 
> 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:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783719: xserver-xorg-video-intel_2:2.99.917-1~exp1 scrolling bug

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi,

On Wed, Apr 29, 2015 at 6:18 AM, Nima Maleki  wrote:
> Package: xserver-xorg-video-intel
> Version: 2:2.99.917-1~exp1
>
> Dear all,
>
> I'd like to apologize for any failings in this report, this is my first
> bug report. Suggestions on how to improve future reports are welcome.

Please use reportbug so that pertinent information like package
versions, etc., is collected automatically.

> This package results in black lines that obscure across rows after
> scrolling within certain text fields. I experienced this problem when
> trying to add to the Debian wiki and tried to scroll down the website's
> text box in order to add comments to an article.
>
> This bug does not occur when scrolling through any other browser
> interface or when scrolling down a text document with a text editor (I
> used Geany) or using LibreOffice.
>
> I solved the error by doing the following:
>
> I creating a configuration file in the following location:
> /etc/X11/xorg.conf.d/20-intel.conf
>
> The file included the following content:
> Section "Device"
>Identifier  "Intel Graphics"
>Driver  "intel"
>Option  "AccelMethod"  "uxa"
> EndSection
>
> I tested with AccelMethod "glamor" and "sna" as well. Those did not
> resolve the problem. Only "uxa" worked for me.
>
> This seems to have, thus far, solved the problem. I've yet to encounter
> any other issues.
>
> I'm using Debian 8
> DE: Gnome 3.14, stock provided by Jessie installation
> My kernel: 3.16.0-4-amd64
> Using (Debian GLIBC 2.19-18) 2.19
>
> Package info:
> Depends: libc6 (>= 2.17), libdrm-intel1 (>= 2.4.38), libdrm2 (>=
> 2.4.25), libpciaccess0 (>= 0.8.0+git20071002), libpixman-1-0 (>=
> 0.30.0), libudev1 (>= 183), libx11-6, libx11-xcb1, libxcb-dri2-0,
> libxcb-dri3-0, libxcb-sync1, libxcb-util0 (>= 0.3.8), libxcb1,
> libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3,
> libxinerama1, libxrandr2 (>= 2:1.2.99.2), libxrender1, libxshmfence1,
> libxtst6, libxv1, libxvmc1, xorg-video-abi-18, xserver-xorg-core (>=
> 2:1.15.99.903)
>
> CPU: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
> Graphics: Broadwell-U Integrated Graphics, i915 driver

Please file a bug report upstream; instructions can be found at [1].

Regards,
Vincent

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


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

Bug#756522: bumblebee-nvidia: cannot access secondary gpu - error: Permission denied

[Vincent Cheng]

Hi Jean,

On Wed, Apr 29, 2015 at 5:06 AM, Jean Bernon Free  wrote:
>  I. On Wed, 29 Apr 2015 03:57:53 -0700 Vincent Cheng
>  wrote:
>> Hi,
>>
>> On Wed, Apr 22, 2015 at 6:48 AM, JEBE  wrote:
>> > Package: bumblebee
>> > Version: 3.2.1-7
>> > Followup-For: Bug #756522
>> >
>> > Dear Maintainer,
>> >
>> > I installed bumblebee and primus packages, not bumblebee-nvidia. But I get 
>> > the
>> > exact same issues and logs than described here.
>> [...]
>> > My bumblebee.conf has the line "driver= ". I understand that only
>> > "xorg.conf.nouveau" is active. Is that correct?
>>
>> Yes, if you only have either nvidia or nouveau installed, not both,
>> bumblebee will detect that (if you have both installed, bumblebee will
>> default to nvidia).
>>
>> [...]
>> > [  6143.889] (EE) [drm] KMS not enabled
>> > [  6143.889] (EE) No devices detected.
>>
>> Hmm...do you have nomodeset or nouveau.modeset=0 specified somewhere
>> (e.g. on your grub command line)? Is your GPU supported by nouveau?
>>
>> Regards,
>> Vincent
>>
>>
> Hi Vincent,
>
> Thanks for your attention.
>
> I have neither bumblebee-nvidia package or other nvidia driver
> installed.
>
> I had no nouveau.modeset option in grub. I tried to boot either with
> nouveau.modeset=1 option or with nouveau.nomodeset=0 option. It doesn't
> change anything in Xorg.8.log.
>
> Above the error you underlined, we found these lines in Xorg.8.log. They
> seem to show 1) that nouveau is loaded 2) that my GPU (Geforce 840M)
> should be supported. No ?

I'm actually not too sure about that. AFAIK the 840M is part of the
Maxwell family [1], and I don't actually know if the kernel/userspace
components are new enough in Debian to support Maxwell cards (your X
log suggests not?). You may have to do some googling to figure it out
for yourself.

Regards,
Vincent

[1] http://nouveau.freedesktop.org/wiki/CodeNames/


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

Bug#784017: override: mailnag:mail/optional

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Hi,

Please change mailnag's section from "gnome" to "mail", reason being that
mailnag has evolved from being GNOME-specific to being desktop-agnostic.
Thanks!

Regards,
Vincent


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

Bug#784020: override: kivy:python/optional

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Hi,

Kivy should be moved from extra -> optional since it satisfies the requirements
for being Priority: optional, as defined in Policy 2.5. (I've also changed the
priority defined in d/control in the package itself as of kivy/1.9.0-1.)

Regards,
Vincent


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

Bug#773245: git-p4 package in contrib, how to proceed?

[Vincent Cheng]

On Sat, Jan 10, 2015 at 10:12 AM, Luke Diamand  wrote:
> Hi!
>
> I'm trying to create a package  for 'git-p4', a python script which mirrors
> between git and Perforce (the latter is a proprietary version control
> system). I'm looking for advice on the best way to do this.
>
> The source code lives in the upstream git repository, but isn't packaged
> with the regular 'git' package because of the proprietary nature of
> Perforce. I thought I'd try to create a separate package that could go into
> contrib instead.
>
> I've created a bug report with a patch for the git package to implement this
> (773245) which Jonathan Nieder was kind enough to look at, but I'm
> struggling to understand what I should do next!
>
> Is it going to be possible to get the regular git package to generate a
> secondary package in contrib? Or would I be better off with a new standalone
> package?

Yes, source packages in main can generate binary packages in contrib;
Policy does not prevent this from happening, and there are existing
source packages in main, in the archive, which generate binary
packages in contrib. See e.g. src:nvidia-settings (and #747837 which
was what prompted one of the binary packages built from it to be moved
from contrib to main).

Regards,
Vincent


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

Bug#775153: wesnoth-1.12-tools: Replace data/tools/wmlxgettext with utils/wmlxgettext.

[Vincent Cheng]

Hi Oleksandr,

On Sun, Jan 11, 2015 at 5:20 PM, Oleksandr Gavenko  wrote:
> Package: wesnoth-1.12-tools
> Version: 1:1.12.0-1
> Severity: normal
>
> Python data/tools/wmlxgettext script isn't useful and experimental and still
> dated at 2007.
>
> That script shown on run:
>
>
>   You probably want to use 'utils/wmlxgettext' instead
>   This script was intended as a replacement but is not currently used
>   It does not generate the same results as the perl version anymore
>   This is not the wmlxgettext script you're looking for
>
>
> Upstream for gettext uses Perl utils/wmlxgettext.
>
> Please replace this script by Perl version.

Will do, thanks for the bug report! Incidentally, do you know if there
are any other obsolete scripts shipped in wesnoth-1.12-tools, or any
scripts that should be shipped but are not?

Regards,
Vincent


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

Bug#774662: Please package the latest upstream release 0.4.11

[Vincent Cheng]

Hi Markus,

On Tue, Jan 6, 2015 at 12:16 AM, Markus Koschany  wrote:
> On Tue, 06. Jan 08:08 Martin Quinson  wrote:
>> On Tue, Jan 06, 2015 at 07:48:36AM +0100, Markus Koschany wrote:
>> > On Tue, 06. Jan 07:36 Martin Quinson  wrote:
>> > > Hello,
>> > >
>> > > could you please attach the debdiff of your changes to the bug report?
>> > > You simply have to call debdiff on the dsc files (iirc).
>> >
>> > I'm a member of the team remember? ;-) Check out the git repository.
>>
>> Oups sorry, I got misguided by the bug title. You already did the
>> packaging and we need to upload it, right? I feel bad about uploading
>> a new upstream release during the freeze, but there is nothing
>> forbiding it formally, I guess.
>
> Hi,
>
> Indeed I'm looking for a sponsor. Everything is ready in Git. I just
> wanted to track the issue with this bug report. Experimental
> would be fine as well of course.
>

Are you still looking for a sponsor for minetest, or is this blocked
on something? The package in git looks fine to me, so I'd like to
upload it to experimental. Unless Martin has any objections, perhaps?

Regards,
Vincent


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

Bug#774662: Please package the latest upstream release 0.4.11

[Vincent Cheng]

On Sat, Jan 17, 2015 at 2:46 AM, Markus Koschany  wrote:
> Hey Vincent,
>
> On 17.01.2015 11:40, Vincent Cheng wrote:
> [...]
>> Are you still looking for a sponsor for minetest, or is this blocked
>> on something? The package in git looks fine to me, so I'd like to
>> upload it to experimental. Unless Martin has any objections, perhaps?
>>
>
> Yes, indeed. I'm quite happy with the current result. I guess Martin is
> busy at the moment but experimental should be fine anyway.

Uploaded and tagged in git, thanks!

Regards,
Vincent


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

Bug#763272: workaround

[Vincent Cheng]

Control: forwarded -1 https://github.com/Bumblebee-Project/Bumblebee/issues/592

On Sun, Sep 28, 2014 at 2:05 PM, Robert Lange  wrote:
> I found a reference to the same issue from an Arch user:
>
> https://github.com/Bumblebee-Project/Bumblebee/issues/592
>
> The workaround given was to append acpi_osi=\"!Windows 2013\" to the
> GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub and run
> update-grub.
>
> After doing this, bumblebee is again able to toggle the discrete chip on and
> off.

If it's really a kernel/ACPI issue like the above bug report suggests,
then there's nothing I can do as bbswitch/bumblebee maintainer to fix
this, sorry. Consider filing a bug report against the kernel.

Regards,
Vincent


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

Bug#764306: RM: src:etm-qt -- ROM; deprecated and superseded by etm

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

Please remove src:etm-qt from the archive. It has been replaced and superseded
by src:etm. Thanks!

Regards,
Vincent


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

Bug#764403: primus-libs:amd64: libGL is too old with driconf/xdriinfo and nouveau

[Vincent Cheng]

Hi Adrian,

On Tue, Oct 7, 2014 at 12:34 PM, Adrian Lang  wrote:
> Package: primus-libs
> Version: 0~20131127-2
> Severity: important
>
> With linux 3.14-2 and xserver-xorg-video-nouveau 1:1.0.11-1, I get the 
> following
> errors with primus:
>
> $ optirun -b primus xdriinfo
> libGL is too old.
> $ optirun -b primus driconf
> libGL is too old.
> $ primusrun driconf
> libGL is too old.
> $ primusrun xdriinfo
> libGL is too old.
>
> Using virtualgl or normal driver does not give these errors.

By "normal driver", do you mean the proprietary nvidia driver?

Does this error still persist if you try rebuilding primus?

Regards,
Vincent


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

Bug#764403: primus-libs:amd64: libGL is too old with driconf/xdriinfo and nouveau

[Vincent Cheng]

On Wed, Oct 8, 2014 at 11:48 AM, Adrian Lang  wrote:
> On Tue, 7 Oct 2014 23:24:12 -0700 Vincent Cheng  wrote:
>> By "normal driver", do you mean the proprietary nvidia driver?
>
> No, I mean intel driver with intel card.
>
>> Does this error still persist if you try rebuilding primus?
>
> Yes, I just rebuilt primus and primus-libs:amd64 and I still get the
> same error.

Can you please file a bug report upstream at [1]? Also, if you're
willing to try the proprietary nvidia driver, can you please test with
that as well?

[1] https://github.com/amonakov/primus/issues/new


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

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Vincent Cheng]

Hi Andrei,

On Thu, Oct 9, 2014 at 1:53 PM, Andrei POPESCU  wrote:
> Package: libgl1-nvidia-glx
> Version: 340.46-1
> Severity: important
>
> Hi,
>
> If I have KMS active I get this when trying to install or upgrade
> libgl1-nvidia-glx:
>
> root@sid:~# dpkg -i libgl1-nvidia-glx_340.46-1_i386.deb
> (Se citește baza de date ... 197382 de fișiere și directoare actualmente 
> instalate.)

LC_ALL=C, please (for future bug reports). Your typical package
maintainer is much more likely to speak English than Romanian.

> If I try it again the script
> /usr/lib/nvidia/check-for-mismatching-nvidia-module gets stuck in D
> state. Also the bug script for the package gets stuck, I had to switch
> to disable KMS to be able to use reportbug.

It may be worth adding "set -x" to the script to see precisely where
it's getting stuck.

My only other suggestion at this point is to try out older versions of
the kernel and/or the nvidia packages, and see if there's a known good
combination that works (is this a regression of some sort?). Other
than that, I've no idea what's happening.

Regards,
Vincent


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

Bug#779319: [Python-modules-team] Bug#779319: python-pygame: Package python-pygame 1.9.2 released 12-12-14

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi,

On Thu, Feb 26, 2015 at 5:28 PM, shirish शिरीष  wrote:
> Package: python-pygame
> Version: 1.9.2~pre~r3348-1
> Severity: wishlist
>
> Dear Maintainer,
> Python-pygame was released on 12th December 2014. Can we have that in
> experimental rather than the pre version one which we have now.

The newest released version of pygame on either pygame.org [1] or the
official bitbucket repo [2] is still 1.9.1; there was no newer release
on Dec. 12, 2014, AFAIK. If there was, can you please provide a link?

Regards,
Vincent

[1] http://pygame.org/download.shtml
[2] https://bitbucket.org/pygame/pygame


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

Bug#779295: nvidia-driver: Problems with software using OpenGL after nvidia-driver install

[Vincent Cheng]

Hi,

On Thu, Feb 26, 2015 at 9:22 AM, José Luis García Pallero
 wrote:
> Package: nvidia-driver
> Version: 340.65-2
> Severity: important
>
> Dear Maintainer,
>
> I have a laptop running Debian Sid with an integrated Intel graphic card and a
> NVIDIA Quadro K2100M. I want use the Quadro ONLY for CUDA tests and the Intel
> card for the normal day work. Until now, I usually install the *.run NVIDIA
> driver (blacklisting the nouveau kernel module) but I configure the xorg.conf
> in order to use the Intel graphic card (see below the <<
> /etc/X11/xorg.conf >> section). One problem of this procedure is that
> after the NVIDIA driver installation I can't use some programs that use OpenGL
> for drawing, line the native graphics of GNU Octave (either the official 
> Debian
> package or the program compiled by myself). The error emitted by Octave is:
>
> Xlib:  extension "GLX" missing on display ":0".
> Xlib:  extension "GLX" missing on display ":0".
> Insufficient GL support
>
> A trick to fix it consist on reinstall the debian packages libgl1-mesa-swx11
> and libgl1-mesa-swx11-dev. I suppose this internally changes the libGL et al.
> in a way that I can use programs that need OpenGL and also I can use CUDA. 
> This
> way to proceed works until the NVIDIA driver version (included) 340.65. For
> higher driver versions the trick of reinstalling libgl1-mesa-swx11 and libgl1
> -mesa-swx11-dev doesn't works, but the Xlib:  extension "GLX" missing on
> display ":0" error still appears.
>
> Well, at this point I decided to install the Debian nvidia-driver package
> (which uses the 340.65 driver). As a consequence, the libgl1-mesa-swx11 and
> libgl1-mesa-swx11-dev packages were uninstalled. I reboot the computer using
> still the corg.conf for the Intel graphic card. The problem is that the Xlib:
> extension "GLX" missing on display ":0" error appears again and I can't use
> programs that use OpenGL. I can see that in the /usr/lib/x86_64-linux-gnu/
> folder exist the correct files libGL, libGLU, libGLESv1, libGLESv2, etc., so I
> don't understand the "Insufficient GL support" error message. I don't know if
> it is a bug in the nvidia-driver package
>
> I've also tried to use the NVIDIA card as the default graphic card. I've run
> nvidia-xconfig, which generated the xorg.conf file:
>
> 
> # nvidia-xconfig: X configuration file generated by nvidia-xconfig
> # nvidia-xconfig:  version 340.46  (buildd@brahms)  Tue Oct  7 08:00:32 UTC
> 2014
>
> Section "ServerLayout"
> Identifier "Layout0"
> Screen  0  "Screen0"
> InputDevice"Keyboard0" "CoreKeyboard"
> InputDevice"Mouse0" "CorePointer"
> EndSection
>
> Section "Files"
> EndSection
>
> Section "InputDevice"
> # generated from default
> Identifier "Mouse0"
> Driver "mouse"
> Option "Protocol" "auto"
> Option "Device" "/dev/psaux"
> Option "Emulate3Buttons" "no"
> Option "ZAxisMapping" "4 5"
> EndSection
>
> Section "InputDevice"
> # generated from default
> Identifier "Keyboard0"
> Driver "kbd"
> EndSection
>
> Section "Monitor"
> Identifier "Monitor0"
> VendorName "Unknown"
> ModelName  "Unknown"
> HorizSync   28.0 - 33.0
> VertRefresh 43.0 - 72.0
> Option "DPMS"
> EndSection
>
> Section "Device"
> Identifier "Device0"
> Driver "nvidia"
> VendorName "NVIDIA Corporation"
> EndSection
>
> Section "Screen"
> Identifier "Screen0"
> Device "Device0"
> Monitor"Monitor0"
> DefaultDepth24
> SubSection "Display"
> Depth   24
> EndSubSection
> EndSection
> **
>
> But surprisingly, I can't start the X environment, so I need to use again the
> xorg.conf for Intel (I don't know if this error is due to the use of the *.run
> driver from NVIDIA). This is really not important to me, because I want to use
> for the X environment the Intel graphics

Given the above, it sounds like you have a Nvidia Optimus system (i.e.
dual intel and nvidia GPUs on one system). The most common solution
for that is bumblebee [1], but if the only thing you're going to use
your nvidia card for is CUDA, my understanding is that you don't
actually need bumblebee (although some of its components may help,
e.g. bbswitch [2]).

Either way, throw out your nvidia-xconfig generated xorg.conf (your
main X display is always driven by your intel card, not nvidia), and
if you choose not to install Debian's bumblebee packages, make sure
you manually update your libGL symlinks via alternatives (you want
mesa's implementation, not nvidia's), e.g.

# update-alternatives --config glx
There are 2 choices for the alternative glx (providing /usr/lib/glx).

  SelectionPathPriority   Status
---

Bug#797214: wesnoth: The wesnoth metapackage can't be installed on sid

[Vincent Cheng]

forcemerge 793284 797214
thanks

Hi Lorenzo,

On Fri, Aug 28, 2015 at 7:08 AM, Lorenzo Beretta  wrote:
> Package: wesnoth
> Severity: normal
>
> Dear Maintainer,
>
> I removed wesnoth because it was in conflict with some security update
> - I forgot which one because it was a few weeks ago, sorry.
> Now the situation is as follows:
> $ apt-get install --dry-run wesnoth
> 
> The following packages have unmet dependencies:
>  libstdc++6 : Breaks: wesnoth-1.12-core (<= 1:1.12.4-1) but 1:1.12.4-1 is to 
> be installed
>  libstdc++6:i386 : Breaks: wesnoth-1.12-core (<= 1:1.12.4-1) but 1:1.12.4-1 
> is to be installed
> E: Broken packages
>
> While
> $ apt-get install --dry-run wesnoth-1.13
> looks like it will install just fine.

This is related to the gcc-5 transition currently ongoing in sid, and
is documented in #793284.

Regards,
Vincent

Bug#797317: nvidia-legacy-340xx-driver: Missing package libgl1-nvidia-legacy-340xx-glx-i386 and no i386 binaries

[Vincent Cheng]

Hi Nicolas,

On Sat, Aug 29, 2015 at 6:40 AM, Nicolas Le Cam  wrote:
> Package: nvidia-legacy-340xx-driver
> Version: 340.76-6
> Severity: normal
>
> Dear Maintainer,
>
> The package recommends libgl1-nvidia-legacy-340xx-glx-i386 but this package 
> doesn't exist and no binaries for i386 either.

This is because nvidia-graphics-drivers-legacy-340xx is a recently
uploaded package and the Debian release team hasn't approved the
package to be autobuilt on Debian's buildd network yet (so the
packages aren't yet available for i386). The initial request can be
found here [1] and I've pinged the release team again today, so it's
just a matter of waiting until it gets approved.

Regards,
Vincent

[1] 
https://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2015-August/011426.html

Bug#567033: dh: Install binaries to /usr/games if Section=games

[Vincent Cheng]

On Mon, Aug 31, 2015 at 12:34 PM, Niels Thykier  wrote:
> Control: tags -1 moreinfo
>
> On Tue, 26 Jan 2010 20:56:26 +0100 Moritz Muehlenhoff 
> wrote:
>> Package: debhelper
>> Version: 7.4.11
>> Severity: wishlist
>>
>> AFAICS dh is designed to automate as much as possible. It would be
>> nice if binaries were automatically installed to /usr/games if
>> the Section in debian/control is "games".
>>
>> Cheers,
>> Moritz
>>
>> [...]
>
> Hi,
>
> Are we still using /usr/games for games?  AFAICT, the use of /usr/games
> is optional, so it is not clear to me that this desired?  The last I can
> find on this in Debian is [1], which is 1½ years after this bug was filed.

AFAIK the Debian games team doesn't have a specific policy that
mandates the use of either /usr/games or /usr/bin, but all the team
packages that I maintain install binaries into /usr/games, and that
seems to hold true for most if not all of the team's packages.

Regards,
Vincent

Bug#791051: gloox: library transition may be needed when GCC 5 is the default

[Vincent Cheng]

On Tue, Sep 1, 2015 at 12:40 AM, Simon McVittie  wrote:
> Control: tags 791051 + pending
>
> On Sat, 04 Jul 2015 at 00:08:58 -0700, Vincent Cheng wrote:
>> Debdiff below. Please feel free to NMU gloox as needed for the transition.
>
> gloox does not appear to have any build-dependencies that need a transition,
> so I have uploaded to DELAYED/2 with those changes (it's effectively
> a "sponsored upload"). Please let me know if I should reschedule or
> cancel. In particular, if you are happy for this to enter the NEW queue
> immediately, let me know and I will reschedule it to 0-day.

If I'm not mistaken, gnutls28 has to transition first before gloox can
(which is why I've been holding off on uploading this myself).

Regards,
Vincent

Bug#797699: frogatto: Seg faults when entering Dungeon Gateway

[Vincent Cheng]

On Tue, Sep 1, 2015 at 11:04 AM, Taran Lynn  wrote:
> Package: frogatto
> Version: 1.3.1+dfsg-2+b3
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> If I enter the Dungean Gateway level the game will seg fault within a second 
> or
> so. Restarting the game or resaving does not fix the problem.

Please report this bug upstream [1]. Thanks!

Regards,
Vincent

[1] https://github.com/frogatto/frogatto/issues

Bug#791051: gloox: library transition may be needed when GCC 5 is the default

[Vincent Cheng]

On Tue, Sep 1, 2015 at 12:37 PM, Simon McVittie  wrote:
> On 01/09/15 19:59, Vincent Cheng wrote:
>> If I'm not mistaken, gnutls28 has to transition first before gloox can
>> (which is why I've been holding off on uploading this myself).
>
> gnutls28 does build a C++ library, which I'll admit I hadn't previously
> spotted; thanks for noticing that!
>
> However, it has been built since the beginning of August (hence with
> g++-5), and does not appear to have any reference to the cxx11 symbols
> in the `objdump -Tx` output. Also, the headers in /usr/include/gnutls
> only mention std:: symbols std::exception and std::vector, which I
> believe are unaffected. So I don't think gnutls28 needs a transition,
> hence this is still OK.
>
> (Also, Ubuntu haven't done the rename, despite being ahead of Debian in
> many of the other renames due to having a more targeted set of packages.)

Ah, thanks for investigating (I merely assumed that gnutls28 would
need a transition because it's listed in the transition tracker [1]).
In that case, feel free to reschedule it as a 0-day upload.

Regards,
Vincent

[1] https://release.debian.org/transitions/html/libstdc++6.html

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

[Vincent Cheng]

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

Hi,

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

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

Regards,
Vincent

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

[Vincent Cheng]

Hi,

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

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

Regards,
Vincent

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

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

[Vincent Cheng]

On Thu, Sep 3, 2015 at 5:24 PM, Luca Boccassi  wrote:
> On Thu, 2015-09-03 at 14:49 +0200, Alessandro Ghedini wrote:
>> Source: libvdpau
>> Severity: important
>> Tags: security, fixed-upstream
>>
>> Hi,
>>
>> the following vulnerabilities were published for libvdpau.
>>
>> CVE-2015-5198[0]:
>> incorrect check for security transition
>>
>> CVE-2015-5199[1]:
>> directory traversal in dlopen
>>
>> CVE-2015-5200[2]:
>> vulnerability in trace functionality
>>
>> All of them are fixed by the patch [3], shipped in the 1.1.1 upstream
>> release.
>>
>> If you fix the vulnerabilities please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> Hello Alessandro,
>
> Thanks for the heads-up!
>
> Vincent, Andreas,
>
> I have updated the libvdpau git repo with the new release [1]. I have
> tested the amd64 and i386 packages in Jessie, and they seem to work just
> fine with vdpauinfo and VLC.
>
> Could you please review and do a new upload, when you have time?
>
> Thanks!
>
> Tomorrow I'll look into backporting the fix to Wheezy and Squeeze.

Uploaded, thanks! I'll make a note to myself to update the package in
jessie-backports as well. Luca, let me know if you need a sponsor for
the wheezy-pu/jessie-pu or wheezy-security/jessie-security uploads (I
don't know if these CVEs warrant a DSA, so ping the security team
first with a source debdiff and see what they say, and if they say no
then ping the release team instead); thanks for taking care of updates
for stable/oldstable/oldoldstable!

Regards,
Vincent

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

[Vincent Cheng]

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

Regards,
Vincent

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

[Vincent Cheng]

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

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

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

Regards,
Vincent

Bug#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&t=50952

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

[Vincent Cheng]

Control: tags -1 + moreinfo unreproducible

Hi Ben,

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

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

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

Regards,
Vincent

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

Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]

[Vincent Cheng]

Hi James,

On Tue, Jun 9, 2015 at 4:55 PM, James Lu  wrote:
> Hi Vincent,
>
> Wow, that's a lot of magic for one makefile target! I followed the guide,
> setting the file timestamps to the last changelog entry's date, and it works
> fine now. I've uploaded the newest version to mentors.

Using your get-orig-source target, I still get an orig tarball with a
different md5sum (178a964633a9ed23dad36bf2d6a5e9ef) compared to the
tarball you've uploaded to mentors (d1ec1ce2db3cc38f89b07b643ad9d055).

Regards,
Vincent


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

Bug#787902: [Python-apps-team] Bug#787902: pelican: Please provide a python3 module

[Vincent Cheng]

On Sat, Jun 6, 2015 at 12:03 AM, Johannes Schauer  wrote:
> Source: pelican
> Version: 3.5.0-1
> Severity: wishlist
> Tags: patch
>
> Control: block -1 by 787897
>
> Hi,
>
> I noticed that pelican still relies on Python 2 even though upstream
> supports Python 3.
>
> The attached patch rectifies the situation.
>
> The patch can only be applied once feedgenerator offers a Python 3
> module (bug #787897).
>
> While changing the dh --buildsystem to pybuild, I tried getting the test
> suite to work but ran into several problems. Thus I deactivated running
> the test suite for now.

Thanks for the patch! However, as pelican is intended to be used more
as an application (it's a static site generator), rather than a set of
standalone python modules, I don't think it particularly makes sense
to offer both a python2 and python3 version of pelican. I'm inclined
to just build src:pelican using whatever is the default version of
python in Debian, and eventually rename the binary python-pelican
package to just pelican.

Regards,
Vincent


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

Bug#787902: [Python-apps-team] Bug#787902: pelican: Please provide a python3 module

[Vincent Cheng]

On Mon, Jun 15, 2015 at 11:54 PM, Johannes Schauer  wrote:
> Hi,
>
> Quoting Vincent Cheng (2015-06-16 07:18:24)
>> Thanks for the patch! However, as pelican is intended to be used more as an
>> application (it's a static site generator), rather than a set of standalone
>> python modules, I don't think it particularly makes sense to offer both a
>> python2 and python3 version of pelican. I'm inclined to just build
>> src:pelican using whatever is the default version of python in Debian, and
>> eventually rename the binary python-pelican package to just pelican.
>
> I'm neither very familiar with Python packaging nor with the plan to 
> transition
> from Python2 to Python3, but naively I would've thought that when the change 
> of
> the default Python version happens would also depend on the number of packages
> that do not anymore depend on Python2, no? So would any such transition in the
> future not be made easier or earlier if the number of Packages that still
> (Build-)Depend on Python2 would be lower? Sure, pelican is just one small
> package among thousands so what an impact can it make? But, again naively, I
> would've thought that if every tiny package pushes its transition from 2 to 3
> into the future, then together they will lead to the switch of the default
> version from 2 to 3 being later than earlier. You say that it would not make
> much sense to offer both versions at the same time and that is a valid
> argument. But what stops src:pelican from just offering the Python 3 version 
> in
> a "pelican" binary package now?

I haven't been keeping up with all the traffic from debian-python
lately, but my understanding of the current situation is that python
libraries/modules should have both python2 and python3 binary packages
whenever possible (or be ported to python 3 if not yet already
ported), while python application maintainers are free to choose to
use either python2 or python3. IMO for python applications, it makes
sense to just depend on whatever python version is currently the
default, so that end users (many of who are not necessarily python
developers and consider this an implementation detail they don't care
about) end up with just a single (default) version of python
installed.

Regards,
Vincent


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

Bug#711354: local synchronisation works for me

[Vincent Cheng]

Hi Tomas,

On Wed, Jun 17, 2015 at 11:48 AM, Tomas Pospisek  wrote:

> Allthough - gnote has been segfaulting for me recently, and I have activated
> (local) synchronisation recently so ... I'm not sure if "works" is a
> correct term.

Please get a backtrace [1] and file a bug report upstream at [2].

Regards,
Vincent

[1] https://wiki.debian.org/HowToGetABacktrace
[2] http://bugzilla.gnome.org/enter_bug.cgi?product=gnote


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

Bug#789758: racket: New upstream release (6.2) available

[Vincent Cheng]

Package: racket
Version: 6.1.1-3
Severity: wishlist

Dear Maintainer,

Please consider packaging the latest upstream release. Thanks for your work!

Regards,
Vincent

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

Kernel: Linux 4.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 racket depends on:
ii  libc6  2.19-18
ii  libffi63.1-2+b2
ii  racket-common  6.1.1-3

Versions of packages racket recommends:
ii  racket-doc  6.1.1-3

racket suggests no packages.

-- no debconf information


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

Bug#789167: nvidia-legacy-304xx-alternative: alternative for libEGL is missing

[Vincent Cheng]

Hi Andreas,

On Sun, Jun 21, 2015 at 1:01 PM, Andreas Beckmann  wrote:
> Control: tag -1 moreinfo
>
> On 2015-06-18 15:04, Ronny Standtke wrote:
>> glx-alternative-nvidia sets up a slave link for libEGL. The problem is
>> that nvidia-legacy-304xx-alternative doesn't add this slave link, too.
>> This way libEGL is completely missing in the running system when
>> nvidia-legacy-304xx-alternative is selected via update-alternatives.
>> This leads to many instabilities, e.g. no window decoration in KDE
>> because kwin is just crashing...
>
> The EGL and GLES alternatives should work out of the box and fall back
> to MESA if no accelerated implementation is available.

If I'm not mistaken, there might actually be a bug in the packaging
here. It looks like the libEGL symlink is missing from
debian/nvidia-alternative.postinst.in as shipped in
nvidia-graphics-drivers-legacy-304xx/304.125-2 [1], but it's present
in nvidia-graphics-drivers/340.65-2 [2]. I think that's worth fixing
regardless of whether or not falling back to mesa works.

Regards,
Vincent

[1] 
http://sources.debian.net/src/nvidia-graphics-drivers-legacy-304xx/304.125-2/debian/nvidia-alternative.postinst.in/
[2] 
http://sources.debian.net/src/nvidia-graphics-drivers/340.65-2/debian/nvidia-alternative.postinst.in/


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

Bug#789167: nvidia-legacy-304xx-alternative: alternative for libEGL is missing

[Vincent Cheng]

On Wed, Jun 24, 2015 at 1:35 AM, Vincent Cheng  wrote:
> Hi Andreas,
>
> On Sun, Jun 21, 2015 at 1:01 PM, Andreas Beckmann  wrote:
>> Control: tag -1 moreinfo
>>
>> On 2015-06-18 15:04, Ronny Standtke wrote:
>>> glx-alternative-nvidia sets up a slave link for libEGL. The problem is
>>> that nvidia-legacy-304xx-alternative doesn't add this slave link, too.
>>> This way libEGL is completely missing in the running system when
>>> nvidia-legacy-304xx-alternative is selected via update-alternatives.
>>> This leads to many instabilities, e.g. no window decoration in KDE
>>> because kwin is just crashing...
>>
>> The EGL and GLES alternatives should work out of the box and fall back
>> to MESA if no accelerated implementation is available.
>
> If I'm not mistaken, there might actually be a bug in the packaging
> here. It looks like the libEGL symlink is missing from
> debian/nvidia-alternative.postinst.in as shipped in
> nvidia-graphics-drivers-legacy-304xx/304.125-2 [1], but it's present
> in nvidia-graphics-drivers/340.65-2 [2]. I think that's worth fixing
> regardless of whether or not falling back to mesa works.

Oops, ignore what I said above, 304.xx doesn't come with EGL support.

Regards,
Vincent


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

Bug#789483: Found a patch

[Vincent Cheng]

Control: tag -1 + patch

Hi Giuseppe,

On Sun, Jun 21, 2015 at 6:35 AM, Giuseppe Bilotta
 wrote:
> The following patch to uvm/Kbuild seems to fix the problem for me
> (hoping gmail doesn't wrap it)
>
> --- uvm/Kbuild~ 2015-06-21 15:33:08.438616334 +0200
> +++ uvm/Kbuild 2015-06-21 15:33:22.662669880 +0200
> @@ -219,6 +219,8 @@
> RM_MODULE_SYMVERS:= $(RM_OUT_DIR)/Module.symvers
> UVM_MODULE_SYMVERS:= $(obj)/Module.symvers
>
> +KBUILD_EXTRA_SYMBOLS += $(RM_MODULE_SYMVERS)
> +
> module $(MODULE_NAME).ko: $(UVM_MODULE_SYMVERS) debug_diagnostics_printing
>
> $(MODULE_NAME)-y := $(MODULE_GLUE_OBJS)
>

Thanks for the above patch! I'll get it uploaded ASAP along with
nvidia 346.82 sometime this week.

Regards,
Vincent


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

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

[Vincent Cheng]

Hi Kai-Chung,

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

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

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

Regards,
Vincent

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

[Vincent Cheng]

Hi Steve,

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

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

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

Regards,
Vincent

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

[Vincent Cheng]

Hi Sven,

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

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

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

Regards,
Vincent

Bug#790110: override: python-pelican:oldlibs/extra

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

python-pelican is now a dummy transitional package, i.e. oldlibs/extra. Thanks!


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

Bug#790306: Please support ARM64

[Vincent Cheng]

Control: block -1 by 790317

Hi Martin,

On Sat, Jun 27, 2015 at 3:26 PM, Martin Michlmayr  wrote:
> Package: 0ad
> Version: 0.0.18-1
> Severity: wishlist
> Tags: upstream
> User: debian-...@lists.debian.org
> Usertags: arm64
>
> It would be nice if 0 A.D. would support ARM64.  There are Android
> based devices on ARM64 already and I suspect we'll be seeing Linux
> desktop devices based on ARM64 soon as well.
>
> I know this is really an upstream issue, but it would be great if you
> could raise an upstream feature request.
>
> I briefly looked into it and created a patch with some obvious
> locations where ARM64 (or AARCH64, as it's officially called) should
> be added, but I'm sure it's incomplete.  I also noticed
> libraries/source/nvtt where ARM is referenced.

It's worth noting that 0ad build-depends on nvidia-texture-tools in
Debian, so we can ignore the embedded copy of nvtt in 0ad's source.

> Note that I followed the existing code in source/lib/byte_order.h but
> imho this is not an optimal way to do things as e.g. MIPS and ARM can
> be both little or big endian.

Would you consider filing this bug report directly upstream [1][2],
with your patch (just like you did with nvidia-texture-tools)? I'm not
a porter myself and I don't think there's any value in me being a
middleman, in case upstream has any questions to ask you etc. Thanks!

[1] http://trac.wildfiregames.com/newticket
[2] alternatively, upstream is pretty active on IRC (freenode #0ad-dev)


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

Bug#787234: cython: FTBFS on arm64, ...

[Vincent Cheng]

Control: severity -1 serious
Control: retitle -1 cython: FTBFS on arm64, armel, armhf, mipsel

cython FTBFS on arm64, armel, armhf, and mipsel is a regression on
these release archs (cython/0.21.1-1 was built successfully on all
archs), thus raising severity to RC.

Regards,
Vincent


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

Bug#790809: Please enable ARM64 support

[Vincent Cheng]

Hi Martin,

On Wed, Jul 1, 2015 at 2:07 PM, Martin Michlmayr  wrote:
> Package: nvidia-settings
> Version: 340.46-2
> Severity: wishlist
> User: debian-...@lists.debian.org
> Usertags: arm64
>
> I wonder whether it makes sense to build nvidia-settings on ARM64.
> I don't know anything about this package but I know that 64-bit ARM
> Tegra based devices exist with Nvidia chips, so maybe it would be
> useful?  I see it's enabled for armhf, which is probably a similar
> case.  I also see that the package has (some?) support for ARM64
> (search for AARCH64).
>
> I added arm64 to debian/control and it built fine.  I have no way to
> test, though.

This package is dependent on the proprietary nvidia driver, and
upstream currently only releases it for i386, amd64, and armhf
(armv7l) [1]. I don't think there's any point in building
nvidia-settings on arm64 until upstream also releases the
corresponding arm64 version of their proprietary driver.

Regards,
Vincent

[1] http://www.nvidia.ca/object/unix.html


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

Bug#790896: RM: conky [armel] -- ROM; std::exception_ptr is broken on armel

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

The latest conky release makes use of std::exception_ptr, which is
part of libstdc++ on every architecture except for armel. This is a
known bug (see #727621 and [1] in particular).

I'd like to request removal of conky on armel. It doesn't have any
reverse-deps, and there's precedent of packages being removed from
armel due to missing functionality in libstdc++ (#760974). Upstream is
unlikely to rewrite conky to not use C++11 functionality just because
armel is broken.

Regards,
Vincent

[1] https://lists.debian.org/debian-arm/2013/12/msg0.html


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

Bug#790842: conky: Conky sometimes does not update window size

[Vincent Cheng]

Control: tag -1 + moreinfo

Hi Vladimir,

On Thu, Jul 2, 2015 at 2:04 AM, Vladimir Kudrya  wrote:
> Package: conky
> Version: 1.9.0-6
> Severity: normal
>
> Dear Maintainer, sometimes conky stops updating window height.
> When content changes, it either leaves empty space or is clipped beyond 
> window.
> Usually restarting conky corrects this behavior, it updates windows size when
> content changes after restart.
> Presumably, switching compositing, or changing xrandr geometry can trigger
> bug in size update.

Does this still happen with conky/1.10.0-1 (currently in sid)? If so,
please report a bug upstream at [1].

Regards,
Vincent

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


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

Bug#790816: RFS: roxterm/3.0.1-1

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Tony,

On Wed, Jul 1, 2015 at 1:22 PM, Tony Houghton  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "roxterm"
>
>  * Package name: roxterm
>Version : 3.0.1-1
>Upstream Author : Tony Houghton 
>  * URL : http://roxterm.sourceforge.net
>  * License : GPL2+
>Section : x11
>
> It builds these binary packages:
>
>  roxterm- Multi-tabbed GTK+/VTE terminal emulator - binaries
>  roxterm-data - Multi-tabbed GTK+/VTE terminal emulator - data files
>  roxterm-dbg - Debugging symbols for roxterm
>  roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - transitional
> package
>  roxterm-gtk3-dbg - Multi-tabbed GTK+/VTE terminal emulator - transitional
> package
>
> To access further information about this package, please visit the following
> URL:
>
>   http://mentors.debian.net/package/roxterm
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.0.1-1.dsc
>
> More information about roxterm can be obtained from
> http://roxterm.sourceforge.net
>
> Changes since the last upload:
>
> roxterm (3.0.1-1) unstable; urgency=medium
>
>   * Updated Standards-Version to 3.9.6.
>   * Build uses python3 (updated Build-Depends accordingly).
>   * Upstream tarball now uses .xz compression.
>   * Added Select All menu item.
>   * Allow unlimited scrollback lines.
>   * Fixed some unsafe uses of sprintf.
>   * Provide option to rewrap text when terminal width changes.
>   * Drop support for GTK2 etc (Closes: #790183).
>   * Reorganized surviving binary packages.
>   * Use vte-2.91 API (Closes: #788028).
>
>  -- Tony Houghton   Wed, 01 Jul 2015 18:50:46 +0100
>
> roxterm (2.9.7-1) unstable; urgency=low
>
>   * Fixed colour/shortcut shceme CLI switch clash.
>   * Fixed --tab aiming to target most recently focused window.
>
>  -- Tony Houghton   Mon, 30 Mar 2015 18:24:17 +0100
>
> roxterm (2.9.6-1) unstable; urgency=low
>
>   * debian/copyright: Added .ycm_extra_conf.py.in.
>   * Fade text in unselected tabs.
>   * Fix maximise and full screen buttons in profile.
>
>  -- Tony Houghton   Thu, 08 Jan 2015 21:16:21 +
>
> I thought I had released 2.9.6-1 and 2.9.7-1 via sponsorship too, but
> for some reason the current version in unstable is still 2.9.5-1. Is the
> changelog OK as above or should I merge these entries?

Please merge the above d/changelog entries.

I just skimmed the debdiff between 2.9.5-1 and your package on mentors
and noticed a few small things:
- your newly added d/copyright stanza for ".ycm_extra_conf.py.in" has
a License: GPL-3+ header, but the license body references GPL-2
multiple times.
- d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is
quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead
(ditto for CPPFLAGS and LDFLAGS)

Regarding your package split, have you tested other possible upgrade
scenarios? There's a few scenarios I can think of that are broken or
not ideal:
- A user who just has roxterm-gtk2 installed (and roxterm-common
auto-installed), without the roxterm metapackage, will not get any
updates because both of these packages are no longer built from
src:roxterm
- A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from
the same problem as the first scenario, if he/she now chooses to
apt-get install roxterm-dbg, (I think) dpkg will explode due to file
conflicts between roxterm-gtk2-dbg and roxterm-dbg.

And perhaps other scenarios as well, but that's all for now since my
lunch break is over. :)

You should actually keep around dummy transitional packages for every
single package that's currently no longer being built from
src:roxterm. That's probably the simplest way of making sure all
possible upgrade scenarios work (+ double checking package
inter-relationships are correct).

Regards,
Vincent


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

Bug#790939: jessie-pu: package wesnoth-1.10/1:1.10.7-2+deb8u1

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
X-Debbugs-CC: rho...@debian.org

Hi,

I'd like to upload wesnoth-1.10/1:1.10.7-2+deb8u1 to jessie-pu to fix
CVE-2015-5069 and CVE-2015-5070 (these CVEs are marked no-dsa in the
security tracker and the security team has asked me to get these CVEs
fixed via a point update instead). These CVEs have already been fixed
in sid as of wesnoth-1.12/1:1.12.4-1. Debdiff below, thanks!

Regards,
Vincent


diff -Nru wesnoth-1.10-1.10.7/debian/changelog
wesnoth-1.10-1.10.7/debian/changelog
--- wesnoth-1.10-1.10.7/debian/changelog 2015-04-09 03:12:42.0 -0700
+++ wesnoth-1.10-1.10.7/debian/changelog 2015-07-01 13:31:50.0 -0700
@@ -1,3 +1,10 @@
+wesnoth-1.10 (1:1.10.7-2+deb8u1) jessie; urgency=medium
+
+  * Security fix: Disallowed inclusion of .pbl files from WML, independent of
+extension case (CVE-2015-5069, CVE-2015-5070).
+
+ -- Vincent Cheng   Wed, 01 Jul 2015 13:30:12 -0700
+
 wesnoth-1.10 (1:1.10.7-2) unstable; urgency=high

   * Pull af61f9fd from upstream to fix "Private file disclosure through
diff -Nru wesnoth-1.10-1.10.7/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
wesnoth-1.10-1.10.7/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
--- wesnoth-1.10-1.10.7/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
1969-12-31 16:00:00.0 -0800
+++ wesnoth-1.10-1.10.7/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
2015-07-01 13:32:55.0 -0700
@@ -0,0 +1,23 @@
+Description: Disallowed inclusion of .pbl files from WML, independent of
+ extension case (CVE-2015-5069, CVE-2015-5070).
+Origin: upstream, commits 055fea16479a755d6744a52f78f63548b692c440
+ and d20f8015bc3653a10d6d4dfd751e62651d1180b7
+Bug: https://gna.org/bugs/?23504
+Last-Update: 2015-07-01
+
+diff --git a/src/filesystem.cpp b/src/filesystem.cpp
+index 7b4bd95..510da80 100644
+--- a/src/filesystem.cpp
 b/src/filesystem.cpp
+@@ -1157,6 +1157,11 @@ std::string get_wml_location(const std::string
&filename, const std::string &cur
+ return result;
+ }
+
++ if (looks_like_pbl(filename)) {
++ ERR_FS << "Illegal path '" << filename << "' (.pbl files are not
allowed)." << std::endl;
++ return result;
++ }
++
+ bool already_found = false;
+
+ if (filename[0] == '~')
diff -Nru wesnoth-1.10-1.10.7/debian/patches/series
wesnoth-1.10-1.10.7/debian/patches/series
--- wesnoth-1.10-1.10.7/debian/patches/series 2015-04-08
10:14:12.0 -0700
+++ wesnoth-1.10-1.10.7/debian/patches/series 2015-07-01
13:30:05.0 -0700
@@ -1,3 +1,4 @@
 02wesnoth-nolog-desktop-file
 03wesnothd-name
 af61f9fdd15cd439da9e2fe5fa39d174c923eaae.patch
+CVE-2015-5069-CVE-2015-5070.patch


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

Bug#790940: wheezy-pu: package wesnoth-1.10/1:1.10.3-3+deb7u2

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: wheezy
Severity: normal
X-Debbugs-CC: rho...@debian.org

Hi,

I'd like to upload wesnoth-1.10/1:1.10.3-3+deb7u2 to wheezy-pu to fix
CVE-2015-5069 and CVE-2015-5070 (these CVEs are marked no-dsa in the
security tracker and the security team has asked me to get these CVEs
fixed via a point update instead). These CVEs have already been fixed
in sid as of wesnoth-1.12/1:1.12.4-1. Debdiff below, thanks!

Regards,
Vincent


diff -Nru wesnoth-1.10-1.10.3/debian/changelog
wesnoth-1.10-1.10.3/debian/changelog
--- wesnoth-1.10-1.10.3/debian/changelog 2015-04-09 07:00:48.0 -0700
+++ wesnoth-1.10-1.10.3/debian/changelog 2015-07-01 13:51:32.0 -0700
@@ -1,3 +1,10 @@
+wesnoth-1.10 (1:1.10.3-3+deb7u2) wheezy; urgency=medium
+
+  * Security fix: Disallowed inclusion of .pbl files from WML, independent of
+extension case (CVE-2015-5069, CVE-2015-5070).
+
+ -- Vincent Cheng   Wed, 01 Jul 2015 13:30:12 -0700
+
 wesnoth-1.10 (1:1.10.3-3+deb7u1) wheezy-security; urgency=high

   * Pull af61f9fd from upstream to fix "Private file disclosure through
diff -Nru wesnoth-1.10-1.10.3/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
wesnoth-1.10-1.10.3/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
--- wesnoth-1.10-1.10.3/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
1969-12-31 16:00:00.0 -0800
+++ wesnoth-1.10-1.10.3/debian/patches/CVE-2015-5069-CVE-2015-5070.patch
2015-07-01 13:32:55.0 -0700
@@ -0,0 +1,23 @@
+Description: Disallowed inclusion of .pbl files from WML, independent of
+ extension case (CVE-2015-5069, CVE-2015-5070).
+Origin: upstream, commits 055fea16479a755d6744a52f78f63548b692c440
+ and d20f8015bc3653a10d6d4dfd751e62651d1180b7
+Bug: https://gna.org/bugs/?23504
+Last-Update: 2015-07-01
+
+diff --git a/src/filesystem.cpp b/src/filesystem.cpp
+index 7b4bd95..510da80 100644
+--- a/src/filesystem.cpp
 b/src/filesystem.cpp
+@@ -1157,6 +1157,11 @@ std::string get_wml_location(const std::string
&filename, const std::string &cur
+ return result;
+ }
+
++ if (looks_like_pbl(filename)) {
++ ERR_FS << "Illegal path '" << filename << "' (.pbl files are not
allowed)." << std::endl;
++ return result;
++ }
++
+ bool already_found = false;
+
+ if (filename[0] == '~')
diff -Nru wesnoth-1.10-1.10.3/debian/patches/series
wesnoth-1.10-1.10.3/debian/patches/series
--- wesnoth-1.10-1.10.3/debian/patches/series 2015-04-08
10:14:12.0 -0700
+++ wesnoth-1.10-1.10.3/debian/patches/series 2015-07-01
13:51:48.0 -0700
@@ -1,3 +1,4 @@
 02wesnoth-nolog-desktop-file
 03wesnothd-name
 af61f9fdd15cd439da9e2fe5fa39d174c923eaae.patch
+CVE-2015-5069-CVE-2015-5070.patch


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

Bug#791355: conky: Memory allocation error

[Vincent Cheng]

Hi Michael,

On Fri, Jul 3, 2015 at 10:20 AM, Michael Rasmussen  wrote:
> Package: conky
> Version: 1.10.0-1
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> When starting conky everything works but after running approximately 30 min 
> conky crashes with the following output from DEBUG:
> DEBUG(0) [/build/conky-FWDzxw/conky-1.10.0/src/specials.cc:460]: reallocing 
> graph from 303 to 343
> conky: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >= 
> (unsigned long) (nb)' failed.

Please report a bug upstream at [1].

Regards,
Vincent

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


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

Bug#663401: Bug#790809: Please enable ARM64 support

[Vincent Cheng]

On Fri, Jul 3, 2015 at 6:48 AM, Breno Leitao  wrote:
> On Thu, 02 Jul 2015 16:28:20 +0200 Graham Inggs  wrote:
>> There is driver for arm64 available from the CUDA 6.5 download page
> Right. The same driver for ppc64el, and it is working fine...
> https://developer.nvidia.com/cuda-downloads-power8

There's another wishlist bug report asking for the CUDA-specific
driver to be packaged as well, #663401. Whether someone will find the
time to package it is another question entirely...

Does anyone know if nvidia-settings actually works (and is supported
by upstream) with these drivers?

Regards,
Vincent


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

Bug#791051: gloox: library transition may be needed when GCC 5 is the default

[Vincent Cheng]

user release.debian@packages.debian.org
usertag 791051 + transition
block 791051 by 790756
reassign 791051 release.debian.org
tag 791051 + patch
thanks

Hi Matthias,

On Fri, Jul 3, 2015 at 6:10 AM, Matthias Klose  wrote:

>  - If a library transition is needed, please prepare for the change.
>Rename the library package, append "v5" to the name of the package
>(e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
>have a soversion bump and you upload this version instead of the
>renamed package.  Prepare a patch and attach it to this issue (mark
>this issue with patch), so that it is possible to NMU such a
>package. We'll probably have more than hundred transitions
>triggered. Then reassign the issue to release.debian.org and
>properly tag it as a transition issue, by sending an email to
>cont...@bugs.debian.org:

Debdiff below. Please feel free to NMU gloox as needed for the transition.

Regards,
Vincent

diff -Nru gloox-1.0.13/debian/changelog gloox-1.0.13/debian/changelog
--- gloox-1.0.13/debian/changelog 2015-05-08 20:22:24.0 -0700
+++ gloox-1.0.13/debian/changelog 2015-07-03 23:58:19.0 -0700
@@ -1,3 +1,10 @@
+gloox (1.0.13-3) unstable; urgency=medium
+
+  * Rename libgloox13 to libgloox13v5 for libstdc++ ABI transition.
+(Closes: #791051)
+
+ -- Vincent Cheng   Fri, 03 Jul 2015 23:56:03 -0700
+
 gloox (1.0.13-2) unstable; urgency=medium

   * Upload to unstable.
diff -Nru gloox-1.0.13/debian/control gloox-1.0.13/debian/control
--- gloox-1.0.13/debian/control 2015-02-03 23:22:35.0 -0800
+++ gloox-1.0.13/debian/control 2015-07-03 23:59:20.0 -0700
@@ -21,7 +21,7 @@
 Architecture: any
 Multi-Arch: same
 Depends:
- libgloox13 (= ${binary:Version}),
+ libgloox13v5 (= ${binary:Version}),
  libgnutls28-dev,
  libidn11-dev,
  ${misc:Depends}
@@ -35,11 +35,13 @@
  .
  This package contains files needed for development with this library.

-Package: libgloox13
+Package: libgloox13v5
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Replaces: libgloox13
+Conflicts: libgloox13
 Description: C++ jabber/xmpp library
  A C++ Jabber/XMPP library that takes care of low level protocol stuff.
  Additionally, it offers high level interfaces for interaction with an
diff -Nru gloox-1.0.13/debian/libgloox13.install
gloox-1.0.13/debian/libgloox13.install
--- gloox-1.0.13/debian/libgloox13.install 2014-09-20 11:20:12.0 -0700
+++ gloox-1.0.13/debian/libgloox13.install 1969-12-31 16:00:00.0 -0800
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru gloox-1.0.13/debian/libgloox13v5.install
gloox-1.0.13/debian/libgloox13v5.install
--- gloox-1.0.13/debian/libgloox13v5.install 1969-12-31 16:00:00.0 -0800
+++ gloox-1.0.13/debian/libgloox13v5.install 2014-09-20 11:20:12.0 -0700
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*


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

Bug#790816: RFS: roxterm/3.0.1-1

[Vincent Cheng]

On Fri, Jul 3, 2015 at 8:30 AM, Tony Houghton  wrote:

>> - d/rules: CFLAGS = $(shell dpkg-buildflags | grep '^CFLAGS=') is
>> quite brittle; I suggest using dpkg-buildflags --get CFLAGS instead
>> (ditto for CPPFLAGS and LDFLAGS)
>
>
> That's better, I don't know how I missed that, unless it's a recent
> addition to dpkg-buildflags. The way I get the parallel option looks
> quite nasty too, is there a better way to do that?

Not that I know of...I've never really worried about supporting
parallel builds in my own packages, to be honest.

>> Regarding your package split, have you tested other possible upgrade
>> scenarios? There's a few scenarios I can think of that are broken or
>> not ideal:
>> - A user who just has roxterm-gtk2 installed (and roxterm-common
>> auto-installed), without the roxterm metapackage, will not get any
>> updates because both of these packages are no longer built from
>> src:roxterm
>
>
> My thinking is that anybody still using roxterm-gtk2 has some good
> reason to do so and will not want to upgrade to a GTK3 version even if
> it means missing out on the latest features and bug fixes; they are
> already missing out on some useful features from vte-2.90. With the
> relationships the way they are at the moment users can keep roxterm-gtk2
> without having to pin it. I tested that scenario and it seems to work.
> But, since vte9 (the GTK2 version of vte) is scheduled for removal from
> the archive, is this undesirable?

Ah, I didn't realize that this is actually intentional. Well, IMHO
it's saner to offer users an upgrade path by default (i.e. to the gtk3
version), and let them choose to manually pin packages if they don't
want to upgrade for some reason. However, I can't find a Policy
reference that mandates all binary packages to have an upgrade path or
similar, so I'll leave the choice to you.

>> - A user has roxterm-gtk2 and roxterm-gtk2-dbg installed. Aside from
>> the same problem as the first scenario, if he/she now chooses to
>> apt-get install roxterm-dbg, (I think) dpkg will explode due to file
>> conflicts between roxterm-gtk2-dbg and roxterm-dbg.
>
>
> So I should add Breaks: roxterm-gtk2-dbg to roxterm-dbg, and I think it
> would also be more appropriate to move Breaks: roxterm-gtk2 and
> roxterm-gtk3 from roxterm-data to roxterm, because the latter is the
> package that contains the corresponding files. But, if the previous
> point about preventing roxterm-gtk2 from being automatically upgraded is
> OK, I don't want to add Replaces: roxterm-gtk2(-dbg).

Ack, roxterm should declare Breaks: roxterm-gtk2 (in addition to
-gtk3) and roxterm-dbg should declare Breaks: roxterm-gtk2-dbg (in
addition to -gtk3-dbg). Why wouldn't you want the equivalent Replaces
relationships here as well? Having roxterm declare Replaces:
roxterm-gtk2 is not going to force roxterm-gtk2 to be automatically
upgraded in the first scenario I described in my last email (where the
user has roxterm-gtk2 and roxterm-common installed, but not roxterm;
nothing gets upgraded in this scenario). Without Replaces, users who
currently have only roxterm-gtk2 and roxterm-common installed, who
then decide to switch to the gtk3 version by running apt-get install
roxterm, can't do so (at least, not without removing roxterm-gtk2
first).

Regards,
Vincent


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

Bug#790816: RFS: roxterm/3.0.1-1

[Vincent Cheng]

On Sat, Jul 4, 2015 at 7:35 AM, Tony Houghton  wrote:

> One other point I noticed is that currently I have roxterm-data Breaks
> and Replaces roxterm << 3.0.0-1 (actually I put 2 instead of 3 by
> mistake so that needs changing anyway), where roxterm << 3 is the old
> virtual package. As there is no direct replacement for that, do you
> agree I should keep the Breaks where it is but remove the Replaces?
> Breaks probably isn't strictly necessary either, but it might be a good
> idea just in case there's a clash in /usr/share/doc/roxterm.

If there's an upgrade scenario where file ownership changes from
roxterm to roxterm-data or vice versa (i.e. one package overwrites
files owned by the other), you need to declare both Breaks and
Replaces. So if roxterm and roxterm-data both owned files with the
same name in /usr/share/doc/roxterm or elsewhere, currently or in a
past release, then yes, you'll need both Breaks and Replaces.

(If you have time, please upload an updated package to mentors so it's
easier to discuss any further changes.)

Regards,
Vincent


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

Bug#789526: RFS: trac-mercurial/1.0.0.7+hged4f0932196b-1 [RC]

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Matthias,

On Sun, Jun 21, 2015 at 1:09 PM, Matthias Schmitz  wrote:
> Package: sponsorship-requests
> Severity: important
>
> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my updated package "trac-mercurial"
> which fixes the RC bug #787722.
>
>  Package name: trac-mercurial
>  Version : 1.0.0.7+hged4f0932196b-1
>
> It builds those binary packages:
>
>   trac-mercurial - Mercurial version control backend for Trac
>
> To access further information about this package, please visit the
> Debian tracker and the following URL:
>
>   https://tracker.debian.org/pkg/trac-mercurial
> and
>   http://mentors.debian.net/package/trac-mercurial
>
> Changes since the last upload:
>  * New upstream version Closes: #787722
>  * [6d47d45] Imported Upstream version 1.0.0.7+hged4f0932196b
>  * [738a79e] lintian: Bump standards version
>

Please incorporate and acknowledge the changes from the non maintainer
upload (by simply keeping the NMU d/changelog entry in your updated
package).

Regards,
Vincent


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

Bug#788583: RFS: blktool -- tune low-level block device parameters [ITA]

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Azat,

On Fri, Jun 12, 2015 at 3:36 PM, Azat Khuzhin  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "blktool"
>
>  Package name: blktool
>  Version : 4-7
>  Upstream Author : Jeff Garzik 
>  URL : http://sourceforge.net/projects/gkernel/files/blktool/
>  License : GPL v2
>  Section : admin
>
> It builds those binary packages:
>
>   blktool- tune low-level block device parameters
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/blktool
>
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x http://mentors.debian.net/debian/pool/main/b/blktool/blktool_4-7.dsc
>
> Changes since the last upload:
>
> * QA upload
> * New maintainer. (Closes: #695127).
> * Fix "blktool readonly is broken" (Closes: #641164).
> * bump debhelper version to 9
> * fix changelog-should-mention-qa
> * fix ancient-standards-version 3.7.2.2 (current is 3.9.6)
> * fix vcs-field-not-canonical
> * fix xs-vcs-header-in-debian-control
> * add homepage
>

Why is this upload targeting experimental instead of unstable?

Just a few comments after having reviewed your package (none of these
are strictly blockers, however):
- Drop quilt from build-depends; unneeded because you're using source
format "3.0 (quilt)" (and so dpkg-source handles everything for you),
and also drop debian/README.source (which is more applicable if you're
using quilt without source format 3.0 quilt) and drop
patchsys-quilt.mk from d/rules.
- Please either push your changes to collab-maint, or drop the
Vcs-{Git,Browser} fields in d/control.
- Consider adding patch headers to the other two existing patches
you've applied to this package; I suggest DEP-3 formatted headers [1],
but git format-patch style headers are fine too.
- d/copyright references a versionless symlink to the GPL; please
change it to /usr/share/common-licenses/GPL-2. While you're at it, you
may consider updating d/copyright to follow DEP-5 conventions [2].

Regards,
Vincent

[1] http://dep.debian.net/deps/dep3/
[2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


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

Bug#787800: RFS: iperf3/3.0.11-1

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Raoul,

On Fri, Jun 5, 2015 at 12:59 AM, Raoul Borenius  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "iperf3"
>
>  * Package name: iperf3
>Version : 3.0.11-1
>Upstream Author : Jon Dugan, ESnet
>  * URL : http://software.es.net/iperf/
>  * License : BSD-3-clause
>Section : net
>
> It builds those binary packages:
>
> iperf3 - Internet Protocol bandwidth measuring tool
> libiperf-dev - Internet Protocol bandwidth measuring tool (development files)
> libiperf0  - Internet Protocol bandwidth measuring tool (runtime files)
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/iperf3
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/i/iperf3/iperf3_3.0.11-1.dsc
>
> More information about hello can be obtained from http://www.example.com.
>
> Changes since the last upload:
>
> perf3 (3.0.11-1) unstable; urgency=medium
>
>   * new upstream version
>   * bumped standards version to 3.9.6
>

Your changes look ok, but I've noticed that src:iperf3 builds library
packages that are installed into multiarch paths (because you're using
dh compat level 9), but your packages are not actually
multiarch-ified. Please implement multiarch support in your package
[1].

Regards,
Vincent

[1] https://wiki.debian.org/Multiarch/Implementation


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

Bug#787802: RFS: i2util/1.2-2

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Raoul,

On Fri, Jun 5, 2015 at 1:03 AM, Raoul Borenius  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "i2util"
>
>  * Package name: i2util
>Version : 1.2-2
>Upstream Author : Aaron Brown 
>  * URL : http://software.internet2.edu
>  * License : Apache-2.0
>Section : libs
>
> It builds those binary packages:
>
>  i2util-tools - Internet2 utility tools
>  libi2util-dev - Internet2 utility library (development files)
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/i2util
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x http://mentors.debian.net/debian/pool/main/i/i2util/i2util_1.2-2.dsc
>
> More information about hello can be obtained from http://www.example.com.
>
> Changes since the last upload:
>
> i2util (1.2-2) unstable; urgency=medium
>
>   * include pfstore (Closes: #774286)

Your changes look ok, but I've noticed that libi2util-dev builds a
static library that's installed into a multiarch-specific path
(because you're using dh compat level 9), but your package isn't
actually multiarch-ified. Please implement multiarch support in your
package [1].

Regards,
Vincent

[1] https://wiki.debian.org/Multiarch/Implementation


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

Bug#787801: RFS: bwctl/1.5.4+dfsg1-1

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Raoul,

On Fri, Jun 5, 2015 at 1:08 AM, Raoul Borenius  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "bwctl"
>
>  * Package name: bwctl
>Version : 1.5.4+dfsg1-1
>Upstream Author : Aaron Brown 
>  * URL : http://www.internet2.edu/performance/bwctl/
>  * License : Apache-2.0
>Section : net
>
> It builds those binary packages:
>
>  bwctl-client - bandwidth test controller (client)
>  bwctl-server - bandwidth test controller (server)
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/bwctl
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/b/bwctl/bwctl_1.5.4+dfsg1-1.dsc
>
> More information about bwctl can be obtained from 
> http://www.internet2.edu/performance/bwctl/
>
> Changes since the last upload:
>
> bwctl (1.5.4+dfsg1-1) unstable; urgency=medium
>
>   * new upstream version
>
>   Regards,
>Raoul Gunnar Borenius
>

I tried generating a source tarball using your get-orig-source target,
but the hashsum doesn't match the tarball you uploaded to mentors.
Please ensure your get-orig-source target produces a reproducible
source tarball (the developers spearheading the reproducible builds
effort have a bunch of helpful wiki pages for this, e.g. [1]).

Regards,
Vincent

[1] https://wiki.debian.org/ReproducibleBuilds/TimestampsInTarball


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

Bug#788583: RFS: blktool -- tune low-level block device parameters [ITA]

[Vincent Cheng]

Hi Azat,

On Sat, Jul 4, 2015 at 3:54 PM, Azat Khuzhin  wrote:
> On Sat, Jul 04, 2015 at 03:12:21PM -0700, Vincent Cheng wrote:
>> Why is this upload targeting experimental instead of unstable?
>>
>> Just a few comments after having reviewed your package (none of these
>> are strictly blockers, however):
>> - Drop quilt from build-depends; unneeded because you're using source
>> format "3.0 (quilt)" (and so dpkg-source handles everything for you),
>> and also drop debian/README.source (which is more applicable if you're
>> using quilt without source format 3.0 quilt) and drop
>> patchsys-quilt.mk from d/rules.
>> - Please either push your changes to collab-maint, or drop the
>> Vcs-{Git,Browser} fields in d/control.
>
> Hi Vincent,
>
> Thanks for comments, I'm going to fix them all.

Great, let me know if you have any questions.

> As for collab-maint, I've just send a request to join to the project via
> [1], could you send email with acknowledge by request?

What's your Alioth username?

Regards,
Vincent


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

Bug#791390: RFS: wxmaxima/15.04.0-1

[Vincent Cheng]

Control: tag -1 + moreinfo
Control: owner -1 !

Hi Gunter,

On Sat, Jul 4, 2015 at 2:03 AM, Gunter Königsmann  wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "wxmaxima"
>
> * Package name: wxmaxima
>   Version : 15.04.0-1
>   Upstream Author : Andrej Vodopivec 
> * URL : http://andrejv.github.io/wxmaxima/
> * License : GPL-2+
>   Section : math

Some comments after having reviewed your package, in no particular order:
- d/changelog is missing the latest upload, 13.04.2-4; please don't
drop old changelog entries
- In general, please be more verbose in d/changelog ("Updated the
dependencies" - list them explicitly). Additional things to consider
including in d/changelog: adding/changing/removing build-deps/deps,
updating standards version, adding/refreshing/removing patches,
dropping the debian menu entry + icons.
- d/control: please add a Vcs-Browser field
- d/control: wxmaxima should depend on fonts-jsmath, not ttf-jsmath
(latter is just a transitional dummy package)
- d/copyright (blockers): specify which version of GPL the package is
licensed under, and change the versionless GPL symlink
"/usr/share/common-licenses/GPL" accordingly; also, CC-BY-SA 2.5 is
not DFSG-compatible (but >= 3.0 is) [1]. For licenses that are not
included in /usr/share/common-licenses, you must add the full text of
the license into d/copyright (not just a link to a creativecommons.org
webpage).

Regards,
Vincent

[1] 
https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_Share-Alike_.28CC-BY-SA.29_v3.0


--
To UNSUBSCRIBE, email to debian-bugs-dist-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  wrote:
> Hi ftpmasters,
>
> On Sun, Aug 10, 2014 at 1:51 AM, mejiko
>  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-dist-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  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#606310: patch for NMU available

[Vincent Cheng]

Hi Gianfranco,

On Mon, Sep 8, 2014 at 3:27 AM, Gianfranco Costamagna
 wrote:
> Hi maintainer,
>
> I have prepared a NMU fixing the three bugs listed,
[...]

I assume that you'd like me to sponsor this NMU, given that you cc-ed
me? I have a few concerns with this NMU as-is:

- please don't include unnecessary changes in a NMU, e.g. bumping
standards version; try to make the debdiff as minimal as possible
- in general, I'm reluctant to NMU changes that aren't RC bug fixes,
especially when I don't use the NMU-ed package myself, and especially
without the consent of the current maintainer/uploaders

If you're interested in taking care of this package and doing a clean
sweep to fix a handful on non-RC bugs, I suggest that you adopt and
formally maintain the package directly. If the current maintainer is
MIA and has yet to reply to any of your mail, I suggest you start by
approaching the MIA team [1].

Regards,
Vincentt

[1] https://wiki.debian.org/Teams/MIA


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

Bug#761062: Upgrading from 304.117-1 to 340.32-1 with older graphics card leaves system without X Windows

[Vincent Cheng]

Hi Marvin,

On Tue, Sep 9, 2014 at 1:22 PM, Marvin Renich  wrote:
> Source: nvidia-graphics-drivers
> Version: 340.32-1
> Severity: important
>
> On a machine with a graphics card supported by version 304, but
> relegated to the legacy packages for version 340, upgrading the
> nvidia-kernel-dkms and nvidia-driver packages leaves the system with an
> unusable X Windows system.
>
> The preinst script should determine if the hardware was supported by the
> old version of the package but not the new version, and give the
> sysadmin an opportunity to fail the upgrade, with an appropriate
> explanation.

Most of the heavy lifting can be done with nvidia-detect; I would've
assumed that there was already a debconf prompt provided by
nvidia-graphics-drivers/nvidia-support, but I guess there isn't? In
any case, patches welcome.

I'd like to point out that the various nvidia packages are (supposed
to be) co-installable, letting you pick what driver series to use at
runtime rather than during package installation (and the kernel
modules are patched so that they're versioned as well), so I don't
think we should forcefully fail package installation attempts of
nvidia drivers that aren't compatible with the user's hardware. Again,
probably a debconf prompt invoking nvidia-detect at some point would
be appropriate.

Regards,
Vincent


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

Bug#767945: unblock: nvidia-graphics-drivers/340.46-4

[Vincent Cheng]

Hi,

On Mon, Nov 3, 2014 at 7:33 AM, Andreas Beckmann  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
>
> Please unblock package nvidia-graphics-drivers
>
> fix some misplaced files (#766343) and add missing bits for the 
> reorganization in 340.46-2
>
> unblock nvidia-graphics-drivers/340.46-4

I noticed that #767945 didn't come with a debdiff as requested by the
freeze policy, so attaching a diff between the version in testing
(340.46-3) and in sid (340.46-4).

Regards,
Vincent


nvidia-graphics-drivers_340.46-4.debdiff
Description: Binary data

Bug#768786: unblock: wxglade/0.6.8-2.2

[Vincent Cheng]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-CC: georg...@debian.org

Hi,

I'd like to upload wxglade/0.6.8-2.2 as a NMU to
testing-proposed-updates to fix RC bug #766743. I'm suggesting an
upload to t-p-u because the version of wxglade in sid contains changes
that don't look suitable for jessie at this point (among other things,
a new upstream release); I just cherrypicked the relevant changes from
the package in sid (where this bug is marked as fixed).

AFAIK it's not possible to upload a package to the delayed queue for
t-p-u, so George, I've cc-ed you in this unblock request; please shout
if you don't want me to upload this for some reason.

unblock wxglade/0.6.8-2.2

diff -Nru wxglade-0.6.8/debian/changelog wxglade-0.6.8/debian/changelog
--- wxglade-0.6.8/debian/changelog 2014-10-12 19:55:16.0 -0700
+++ wxglade-0.6.8/debian/changelog 2014-11-09 01:33:17.0 -0800
@@ -1,3 +1,11 @@
+wxglade (0.6.8-2.2) testing-proposed-updates; urgency=medium
+
+  * Non-maintainer upload.
+  * modified common.py assigned icons_path to '/usr/share/wxglade/icons'
+Closes: #766743
+
+ -- Vincent Cheng   Sun, 09 Nov 2014 01:32:57 -0800
+
 wxglade (0.6.8-2.1) unstable; urgency=low

   * Non-maintainer upload.
diff -Nru wxglade-0.6.8/debian/patches/70-common.py.patch
wxglade-0.6.8/debian/patches/70-common.py.patch
--- wxglade-0.6.8/debian/patches/70-common.py.patch 1969-12-31
16:00:00.0 -0800
+++ wxglade-0.6.8/debian/patches/70-common.py.patch 2014-10-25
09:05:58.0 -0700
@@ -0,0 +1,22 @@
+Index: wxglade-0.6.8/common.py
+===
+--- wxglade-0.6.8.orig/common.py
 wxglade-0.6.8/common.py
+@@ -112,7 +112,7 @@ Path to wxGlade documentation (e.g. html
+ @note: This path will be set during initialisation
+ """
+
+-icons_path = 'icons'
++icons_path = '/usr/share/wxglade/icons'
+ """\
+ Path to wxGlade icons
+
+@@ -374,7 +374,7 @@ def make_object_button(widget, icon_path
+ from tree import WidgetTree
+ id = wx.NewId()
+ if not os.path.isabs(icon_path):
+-icon_path = os.path.join(wxglade_path, icon_path)
++icon_path = os.path.join("/usr/share/wxglade", icon_path)
+ if wx.Platform == '__WXGTK__':
+ style = wx.NO_BORDER
+ else:
diff -Nru wxglade-0.6.8/debian/patches/series
wxglade-0.6.8/debian/patches/series
--- wxglade-0.6.8/debian/patches/series 2014-10-12 18:44:24.0 -0700
+++ wxglade-0.6.8/debian/patches/series 2014-11-09 01:33:46.0 -0800
@@ -5,3 +5,4 @@
 50-setup.py
 transition-towards-wx30.patch
 60-wxpython3.0.patch
+70-common.py.patch


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

Bug#768786: unblock: wxglade/0.6.8-2.2

[Vincent Cheng]

On Sun, Nov 9, 2014 at 8:10 AM, Georges Khaznadar
 wrote:
> Please Vincent, go ahead! and many thanks in advance.
>
> If the unblock query for wxglade-0.7.0 is accepted, wxglade will be part
> of Jessie, but this is not sure.
>
> So please upload wxglade_0.6.8-2.2 now :)

Thanks (both to you and to Jonathan for approving the upload);
uploaded wxglade/0.6.8-2.2 to t-p-u just now.

Regards,
Vincent


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