Bug#968541: O: gnome-shell-mailnag -- mail notification extension for GNOME Shell
Package: wnpp Severity: normal I intend to orphan the gnome-shell-mailnag package. Prospective maintainers should also consider adopting the mailnag package. The package description is: This package provides GNOME Shell integration for Mailnag. It includes the following features: . - Notifies about new mails via the messaging tray (including a counter badge) - Shows an indicator in the top panel (including counter badge and popup menu) - Lock screen integration
Bug#968540: O: mailnag -- extensible mail notification daemon
Package: wnpp Severity: normal I intend to orphan the mailnag package. Prospective maintainers should also consider adopting gnome-shell-mailnag. The package description is: Mailnag is a daemon program that checks POP3 and IMAP servers for new mail. On mail arrival it performs various actions provided by plugins. Mailnag comes with a set of desktop-independent default plugins for visual/sound notifications, script execution etc. and can be extended with additional plugins easily
Bug#968539: O: exaile
Package: wnpp Severity: normal I intend to orphan the exaile package. Exaile has been removed from sid (due to the current packaged version being written in python2 and depending on multiple py2 libraries), but upstream has since released 4.x which now supports python3. Packaging likely needs extensive updates as a result. Description: flexible, full-featured audio player Exaile is a media player which incorporates many of the cool things from Amarok (and other media players) like automatic fetching of album art, handling of large libraries, lyrics fetching, artist/album information via Wikipedia, last.fm support, and optional iPod support (assuming you have python-gpod installed). . In addition, Exaile also includes tabbed playlists (so you can have more than one playlist open at a time), blacklisting of tracks (so they don't get scanned into your library), downloading of guitar tablature from fretplay.com, and submitting played tracks on your iPod to last.fm. . Exaile aims to be similar to AmaroK, but uses Python and GTK+.
Bug#968537: O: tolua++ -- Tool to integrate C/C++ code with Lua - development files
Package: wnpp Severity: normal I intend to orphan the tolua++ package. Note that upstream is effectively dead and this package does not support newer lua releases. The package description is: tolua++5.1 is an extension of toLua, a tool to integrate C/C++ code with Lua. tolua++5.1 includes new features oriented to c++, such as class templates and is compiled with the newest lua 5.1. . Based on a "cleaned" header file, tolua++ automatically generates the binding code to access C/C++ features from Lua. Using Lua-5.1 API and metamethod facilities, the current version automatically maps C/C++ constants, external variables, functions, namespace, classes, and methods to Lua. It also provides facilities to create Lua modules. tolua is a tool that greatly simplifies the integration of C/C++ code with Lua. Based on a cleaned header file, tolua automatically generates the binding code to access C/C++ features from Lua. Using Lua API and tag method facilities, tolua maps C/C++ constants, external variables, functions, classes, and methods to Lua.
Bug#968538: O: dbus-c++ -- C++ API for D-Bus (documentation)
Package: wnpp Severity: normal I intend to orphan the dbus-c++ package. The package description is: Dbus-c++ attempts to provide a C++ API for D-Bus. The library has a glib/gtk and an Ecore mainloop integration. It also offers an optional own main loop.
Bug#968536: O: cherrytree -- hierarchical note taking application
Package: wnpp Severity: normal I intend to orphan the cherrytree package. This package was removed from Debian due to python2 removals; upstream currently has a WIP C++/gtkmm rewrite that can be packaged by a prospective maintainer. The package description is: CherryTree is a hierarchical note taking application, featuring rich text, syntax highlighting, images handling, hyperlinks, import/export with support for multiple formats, support for multiple languages, and more.
Bug#968535: O: logisim -- graphical tool for designing and simulating logic circuits
Package: wnpp Severity: normal I intend to orphan the logisim package. Upstream is no longer actively maintaining this package, but there are a number of forks which are actively maintained that could be packaged instead. The package description is: Logisim is an educational tool for designing and simulating digital logic circuits. With its simple toolbar interface and simulation of circuits as you build them, it is simple enough to facilitate learning the most basic concepts related to logic circuits. With the capacity to build larger circuits from smaller subcircuits, and to draw bundles of wires with a single mouse drag, Logisim can be used (and is used) to design and simulate entire CPUs for educational purposes.
Bug#673426: update ?
Hi Mathieu, On Fri, May 29, 2015 at 5:21 AM, Mathieu Malaterre ma...@debian.org wrote: Some notes: https://github.com/Bumblebee-Project/bumblebee-ppa/issues/30 No progress on this, sorry. It's been sitting on my todo list for a long time, and I'm unsure if I'll ever get around to it at this rate; help with packaging virtualgl would definitely be appreciated! Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tCVm7kCDKzsm1TpY305wcOn_Pju3-mSEepKfFZWhTh=t...@mail.gmail.com
Bug#783887: RFA: simutrans -- transportation simulator
Hi Jörg, On Fri, May 15, 2015 at 1:08 AM, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: Hi Vincent, Am Freitag, den 15.05.2015, 00:39 -0700 schrieb Vincent Cheng: Hi Jörg, On Fri, May 15, 2015 at 12:01 AM, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: Hi, [...] Assuming you plan on joining the team to maintain simutrans, please join the alioth group [1] in order to obtain write access to the Debian Games Team's svn/git repos, subscribe to the team's lists (debian-devel-games, pkg-games-devel), and take advantage of the sponsor queue that we use internally in the team [2] (which I regularly check when sponsoring team packages). More info about the team at [3]. I'm subscribed at both MLs and my application for membership on the alioth group pkg-games is on the way. Good to hear, feel free to go ahead and add your package to the team's sponsors queue (once you've had a chance to prepare the package and update the git repo). Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tDRQeXFJ+qU9Y8zDh9UVi9DfWHAZ5raY3W_hRPmE=q...@mail.gmail.com
Bug#783887: RFA: simutrans -- transportation simulator
Hi Jörg, On Fri, May 15, 2015 at 12:01 AM, Jörg Frings-Fürst deb...@jff-webhosting.net wrote: Hi, if someone can sponsors me, I would to take over the packages. Assuming you plan on joining the team to maintain simutrans, please join the alioth group [1] in order to obtain write access to the Debian Games Team's svn/git repos, subscribe to the team's lists (debian-devel-games, pkg-games-devel), and take advantage of the sponsor queue that we use internally in the team [2] (which I regularly check when sponsoring team packages). More info about the team at [3]. Regards, Vincent [1] https://alioth.debian.org/projects/pkg-games [2] https://wiki.debian.org/Games/Sponsors/Queue [3] https://wiki.debian.org/Games/Team -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tb-48fbf2fgtkg1jm5m6a5vtahikpzq5h54pnffd3h...@mail.gmail.com
Bug#773245: git-p4 package in contrib, how to proceed?
On Sat, Jan 10, 2015 at 10:12 AM, Luke Diamand l...@diamand.org 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-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tBDaXpijNcSyOr8dmT1N=t9q9fntonxqrra06rkhob...@mail.gmail.com
Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it costamagnagianfra...@yahoo.it wrote: Hi Steffen and all, today while talking with a backbox project administrator I discovered that popular tools such as openvas directly calls the amap binary. I never talked with them, but I don't think it is feasible to ask to every security tool provider to patch their code for the only debian benefit. I think I'm then changing again my opinion: the conflict field might be the only proper way to be sure such popular tools (not packaged in debian and some of them not even free) continue to work. Is this one a good reason for a conflict? Again, according to Policy 10.1, as well as precedent that was established by the CTTE decision regarding the namespace collision between ax25-node vs. nodejs, no, it isn't; your argument is no different from that of the nodejs maintainers, arguing that /usr/bin/node should be taken over by nodejs simply because it's already widely used by the nodejs community. If you feel strongly enough about this issue, I'd suggest filing a bug against debian-policy, going through the process and gathering consensus to change 10.1 (e.g. perhaps by weakening it to a should instead of a must, or by proposing a carefully-worded exception to existing policy). Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tax8kynh4emcynsrvdweakohy9vgzbtrvkvqud8pra...@mail.gmail.com
Bug#711833: Request to join python-apps
Hi Alexander, On Mon, May 19, 2014 at 12:05 PM, Alexander Alemayhu alexan...@bitraf.no wrote: Hei, I was on the #debian-python IRC channel on irc.efnet.org earlier. I want to irc.efnet.org? Don't you mean OFTC (or its alias irc.debian.org)? join the python-apps team and have already sent a request in the web interface on alioth. My intention is to adopt postr[0] within the team and maintain it together with Yoann Gauthier. Is there any official process to adopting a package within a team after joining? [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711833 If you intend to join the PAPT, please create an account on Alioth [1] and join the team there in order to get commit access to our svn repos; more info at [2]. I suggest uploading the package to mentors.debian.net (definitely read [3] first) as well to make it easier to review your package. Regards, Vincent [1] https://alioth.debian.org/ [2] https://wiki.debian.org/Teams/PythonAppsPackagingTeam [3] http://mentors.debian.net/intro-maintainers -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tB7+m2=2L7Z4HhHmypRu=y5jz1jnReYtgss3ixM4=x...@mail.gmail.com
Bug#736217: Where is the package?
On Sat, Apr 12, 2014 at 11:31 AM, Tino Mettler tino.mett...@tikei.de wrote: Hi, what happened to the upload? I saw it in the NEW queue a while ago, but it seems it did not enter the archive. It was rejected with the following rationale: Dear Maintainer, unfortunately I have to reject your package. Please add the files that are licensed under LGPL2+ to debian/copyright. (for example ext/codecparsers/gst-libs/gst/codecparsers/gsth264parser.c) You might also want to reconsider the naming of the package: W: libgstreamer-vaapi1.0-0: package-name-doesnt-match-sonames libgstvaapi-1.2-0 libgstvaapi-drm-1.2-0 libgstvaapi-glx-1.2-0 libg stvaapi-x11-1.2-0 Anyways, thanks for reminding me about this. I'll take a look at gstreamer-vaapi again when I have time (probably after exams), but you're of course welcome to help fix the above issues in the meantime. :) Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tckq9k1-a87j7zu26gw-nq2u+eei64zkrjqxufu3yv...@mail.gmail.com
Bug#741094: ITA: pysvn -- A(nother) Python interface to Subversion
Hi Josue, Are you still interested in adopting pysvn, and do you perhaps need a sponsor? If you are, I'd be glad to sponsor your package, especially if it fixes #736300. I also invite you to maintain pysvn within the Debian Python Modules Team. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tawgu8n-sg4hb1pgdkfdh027fukjswkgms8rgjdob8...@mail.gmail.com
Bug#739132: Code copy of older Mozilla code
Hi Emilio, On Wed, Feb 26, 2014 at 11:09 PM, Emilio Pozuelo Monfort po...@debian.org wrote: Hi Vincent, Vincent Cheng wrote: 0ad upstream is already working (and making good progress) on migrating to ESR 24, and should be done in time for their next release. I can't speak on behalf of all the other packages that depend on spidermonkey currently though. Have you seen #739132 ? Do you have any plans to upload mozjs 24? Given mozjs17 hasn't entered testing and has very few rdeps, maybe we could go directly for mozjs24 and work towards getting rid of mozjs17 and mozjs185 (to avoid having several mozjs in testing / stable). I have no plans to upload mozjs 24 (I'd rather not maintain it by myself), but if the iceweasel and/or gnome maintainers would like a helping hand or even a co-maintainer, I'd be glad to help. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACZd_tCFYzCK6c=J_Un1Td=mjujwhxsjmezisg4bsw+mk7j...@mail.gmail.com
Bug#719624: Bug#738282: RFS: xrdp/0.6.1-2 [ITA]
On Mon, Feb 10, 2014 at 8:58 AM, Micheal Waltz eclip...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Feb 9, 2014 at 1:10 AM, Vincent Cheng vch...@debian.org wrote: Control: tag -1 moreinfo On Sat, Feb 8, 2014 at 1:34 PM, Micheal Waltz eclip...@gmail.com wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package xrdp: * Package name: xrdp Version : 0.6.1-2 Upstream Author : Jay Sorg * URL : http://www.xrdp.org/ * License : GPL-2+, other, PD, MIT Section : net It builds those binary packages: xrdp - Remote Desktop Protocol (RDP) server To access further information about this package, please visit the following URL: http://mentors.debian.net/package/xrdp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xrdp/xrdp_0.6.1-2.dsc More information about xrdp can be obtained from http://www.xrdp.org Changes since the last upload: 0.6.1-2 * Remove patch 01reuse-session.patch (Closes: #710007) * Switch to debhelper 9. * set -e in body of postinst script 0.6.1-1 * New Maintainer (Closes: #719624) * New upstream version (Closes: #735678) * Bump standards version Please merge both of these changelog entries into a single entry. Also, the source tarball and the .dsc file that you've uploaded to mentors.debian.net don't match one another: $ dpkg-source -x xrdp_0.6.1-2.dsc dpkg-source: error: file ./xrdp_0.6.1.orig.tar.gz has size 1570266 instead of expected 1570168 Your .dsc says that your source tarball has the following sha1sum hash and size: 04ccace3f69bf92769d5cc89428d0c4f597cdb1d 1570168 xrdp_0.6.1.orig.tar.gz However... $ sha1sum xrdp_0.6.1.orig.tar.gz 14ce17c92c103c2f87e12b7111e3718a70e25680 xrdp_0.6.1.orig.tar.gz Regards, Vincent Vincent, Thank you for looking at my RFS for the xrdp package. I was going to work on the changes mentioned above and re-upload, however last night the original maintainer of the package contacted me regarding the ITA request. He pushed the 0.6.1 update into the official repositories, which I believe triggered mentors.debian.net to see the official repository update and automatically remove the xrdp uploads I did to mentors. I've contacted him directly regarding next steps for continuing the ITA. Are there additional steps I should take regarding the closure of this RFS request? It looks like bartm has already closed your RFS bug, so no need to worry about it. You can of course reopen the bug yourself, but now that you have the maintainer's attention, that probably won't be necessary. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tDhsttxdcMUEK58Kw-Mf=mgexhwvdpg+5asncpmp5u...@mail.gmail.com
Bug#736217: ITP: gstreamer-vaapi -- VA-API plugins for GStreamer
On Tue, Jan 21, 2014 at 12:54 AM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 21.01.2014 09:03, Vincent Cheng wrote: Hi Timo, On Mon, Jan 20, 2014 at 10:45 PM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 21.01.2014 08:25, Vincent Cheng wrote: Package: wnpp Severity: wishlist Owner: Vincent Cheng vch...@debian.org * Package name: gstreamer-vaapi Version : 0.5.7 Upstream Author : Gwenole Beauchesne gwenole.beauche...@intel.com * URL : http://gitorious.org/vaapi/gstreamer-vaapi * License : LGPL-2.1+ Programming Lang: C Description : VA-API plugins for GStreamer gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. Hi, I've had it packaged in git://git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git feel free to reuse whatever you need. Thanks, that saves me quite a bit of work compared to basing off of the current package in Ubuntu! yeah that one is ancient.. earlier 0.5.x didn't build against gst1.0/1.2 so it got stuck at 0.3.6. Updating it to 0.5.7 is still a WIP I've got 0.5.7 built in a clean pbuilder sid chroot (and fixed a bunch of minor issues raised by lintian during the process). Are there any issues blocking upload (perhaps you'd like some time to review my changes?), or can I go ahead and upload the package now? If it interests you, would you like to be the maintainer of gstreamer-vaapi (and move the packaging over to collab-maint while we're at it)? I'd be glad to just sponsor what you have; it spares me additional work and you've already done great work on the package anyways. Works for me, pushed the branches there now and renamed them to match the default names (master, upstream). Thanks, I've gone ahead and pushed my changes there. I've also added pkg-gstreamer-devel and myself to uploaders, but feel free to remove them if you don't approve. Cheers, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tc6qm-xfr_qypv4pkjxwew661gebt3jxab6e+usgkc...@mail.gmail.com
Bug#736217: ITP: gstreamer-vaapi -- VA-API plugins for GStreamer
Control: tag -1 pending On Wed, Jan 22, 2014 at 1:56 AM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 22.01.2014 11:31, Vincent Cheng wrote: On Tue, Jan 21, 2014 at 12:54 AM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 21.01.2014 09:03, Vincent Cheng wrote: Hi Timo, On Mon, Jan 20, 2014 at 10:45 PM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 21.01.2014 08:25, Vincent Cheng wrote: Package: wnpp Severity: wishlist Owner: Vincent Cheng vch...@debian.org * Package name: gstreamer-vaapi Version : 0.5.7 Upstream Author : Gwenole Beauchesne gwenole.beauche...@intel.com * URL : http://gitorious.org/vaapi/gstreamer-vaapi * License : LGPL-2.1+ Programming Lang: C Description : VA-API plugins for GStreamer gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. Hi, I've had it packaged in git://git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git feel free to reuse whatever you need. Thanks, that saves me quite a bit of work compared to basing off of the current package in Ubuntu! yeah that one is ancient.. earlier 0.5.x didn't build against gst1.0/1.2 so it got stuck at 0.3.6. Updating it to 0.5.7 is still a WIP I've got 0.5.7 built in a clean pbuilder sid chroot (and fixed a bunch of minor issues raised by lintian during the process). Are there any issues blocking upload (perhaps you'd like some time to review my changes?), or can I go ahead and upload the package now? looks fine, go ahead! Thanks! Built, signed, and uploaded. Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBa=eef+_mg1-q1ilvoxm0z5qfpmtiets7ztppzitx...@mail.gmail.com
Bug#736217: ITP: gstreamer-vaapi -- VA-API plugins for GStreamer
Package: wnpp Severity: wishlist Owner: Vincent Cheng vch...@debian.org * Package name: gstreamer-vaapi Version : 0.5.7 Upstream Author : Gwenole Beauchesne gwenole.beauche...@intel.com * URL : http://gitorious.org/vaapi/gstreamer-vaapi * License : LGPL-2.1+ Programming Lang: C Description : VA-API plugins for GStreamer gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140121062505.14217.9655.reportbug@vincent-tlaptop
Bug#736217: ITP: gstreamer-vaapi -- VA-API plugins for GStreamer
Hi Timo, On Mon, Jan 20, 2014 at 10:45 PM, Timo Aaltonen tjaal...@ubuntu.com wrote: On 21.01.2014 08:25, Vincent Cheng wrote: Package: wnpp Severity: wishlist Owner: Vincent Cheng vch...@debian.org * Package name: gstreamer-vaapi Version : 0.5.7 Upstream Author : Gwenole Beauchesne gwenole.beauche...@intel.com * URL : http://gitorious.org/vaapi/gstreamer-vaapi * License : LGPL-2.1+ Programming Lang: C Description : VA-API plugins for GStreamer gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. Hi, I've had it packaged in git://git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git feel free to reuse whatever you need. Thanks, that saves me quite a bit of work compared to basing off of the current package in Ubuntu! If it interests you, would you like to be the maintainer of gstreamer-vaapi (and move the packaging over to collab-maint while we're at it)? I'd be glad to just sponsor what you have; it spares me additional work and you've already done great work on the package anyways. Cheers, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tcga1ipu+-pprh8hbrd_t5uyuas8ijsotadd61yq4v...@mail.gmail.com
Bug#728712: RFS: xlsxwriter/0.5.2-1 [ITP] -- A Python module for creating Excel XLSX files
Never mind, looks like this is already in the NEW queue. Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tb0yp9-sr0n5es6buu71eoapboe_uwxdmg__hndaqm...@mail.gmail.com
Bug#724270: ITP: bleachbit -- Free space and maintain privacy
On Sun, Sep 22, 2013 at 11:19 PM, Howard Chan smartbo...@gmail.com wrote: Package: wnpp Severity: wishlist Owner: Howard Chan smartbo...@gmail.com * Package name: bleachbit Version : 0.96 Upstream Author : Andrew Ziem ahz...@gmail.com * URL : http://bleachbit.sourceforge.net * License : GPL-3+ Programming Lang: Python Description : Free space and maintain privacy BleachBit frees space and maintains privacy by quickly wiping files you don't need and didn't know you had. Supported applications include Firefox, Flash, Internet Explorer, Java, Opera, Safari, GNOME, and many others. This is already packaged in Debian, see [1]. Regards, Vincent [1] http://packages.qa.debian.org/bleachbit -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tcon2mwtzl1oxm+m2+u5yot_fwf1mv_58jcm64ydfp...@mail.gmail.com
Bug#705324: ITP: alacarte -- tile renderer for OpenStreetMap using Cairo and MapCSS
Hi, On Fri, Apr 12, 2013 at 10:56 PM, Andrew Shadura bugzi...@tut.by wrote: Package: wnpp Severity: wishlist Owner: Andrew Shadura andre...@debian.org * Package name: alacarte Version : 0.2.1 Upstream Author : Institut für Theoretische Informatik et al. * URL : http://github.com/alacarte-maps/alacarte/ * License : AGPL-3+ Programming Lang: C++11 Description : tile renderer for OpenStreetMap using Cairo and MapCSS alaCarte is a tile renderer for OpenStreetMap data written in C++11, using Cairo for rendering and Boost-Spirit for MapCSS parsing. alacarte is also the name of gnome's menu editor, and is packaged in Debian under the same name [1]. Regards, Vincent [1] http://packages.qa.debian.org/a/alacarte.html -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tCkdX+_phAxv3AXSg3MiDivGUr=bwkqu4e1codgpvg...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 10, 2013 at 10:31 AM, Aron Xu a...@debian.org wrote: On Wed, Apr 10, 2013 at 1:55 PM, Vincent Cheng vincentc1...@gmail.com wrote: Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc bumblebee has been uploaded, but I still have questions about primus. primus has Recommends: primus-libs-ia32 [amd64], this means by default it will pull in some dependency if the users have i386 added to his architecture list. I doubt this is desirable for all cases, users should just install primus-libs:i386 when he needs to run 32bit applications, but not automated by the package manager in such a way? A nice error message indicating that needing a 32bit version of primus-libs would be sufficient to guide the user to install, IMHO. What do you think? Upstream wants to keep that (indeed, I wasn't even planning on including a primus-libs-ia32 package until upstream asked me to re-consider [1]). I acknowledge that this isn't pretty, but I understand upstream's rationale, i.e. that running 32-bit applications with primus is a common enough use case (wine) that we'd want to just push this to end-users by default. And AFAIK there currently is no nice error message for users who try to run a 32-bit application through primus without having installed primus-libs:i386 (unless you consider segfaults to be nice). Is there anything in Policy that would forbid this approach? (I can't think of any I'm not going to insist on keeping that recommends if you revert it (i.e. downgrade to suggests?), but can you please try to convince upstream first in that pull request (again, see [1]), if only for the sake of minimizing the diff between Debian and upstream's PPA and to maintain a healthy relationship with upstream (after making an effort to communicate with upstream, agreeing with their changes, and then just silently reverting the changes in the end anyways?). Thanks! Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10#issuecomment-15251004 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAaMudEMs=5gb528P123O=chm+0yzqbhn3tf5rqqm_...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
First off, sorry for the slow replies lately... On Tue, Apr 9, 2013 at 9:03 AM, Aron Xu a...@debian.org wrote: On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng vincentc1...@gmail.com wrote: On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. Do you think it's time to upload bumblebee? I can now build bumblebee and primus again, but I can't get optirun -b primus to work properly with the latest packages from git, for some reason. Have you given those packages a try for yourself yet? I'm unsure if it's an issue on my end, or something that's expected by upstream right now. Upstream says that Rebasing for Bumblebee is less a good idea, however it's needed to be able to package it using the current packaging scripts [1], so I think that they're aware that the latest code from git is not so stable and we probably shouldn't upload it as is... We could also just revert my latest commits in bumblebee + primus git and just upload packages prior to the removal of primusrun. That'll mean that we'll have to carry primus-nvidia as a transitional package in the future, however. It's either this, or we wait until bumblebee 3.2 + primus get released with upstream's current issues sorted out. Any thoughts? As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. I guess yes? Don't know other people's opinion. It's a minor issue either way. /me shrugs Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBHdVAQq8ifhFKnEc3wqDXhcjUd1_r7rFftGo2YfB+=h...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc They're targeted for experimental, since bbswitch is only available via experimental, and I think it's best to wait for upstream to sort out the few issues remaining before uploading the yet-to-be-released bumblebee 3.2 + latest primus git to unstable. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tD0c_-Uw0jVbPZ38vNRezyF-_96FSSYSKWTVtHre=i...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/issues/11 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbmbyc+rirdqkbdxjdvn45akk7xgnfdzrqv9ajdey1...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just a quick followup... On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). Upstream decided to drop the preinst file (which I was hoping for too), so the above change is no longer relevant anymore. I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P There's been quite a restructuring of the primus packaging lately, done by upstream; primus now queries the bumblebee daemon when it comes to picking nouveau/nvidia, instead of relying on environment variables set in primusrun, so we can now drop primus-nvidia, the duplicate primusrun scripts, and the maintainer scripts / use of the alternatives system (i.e. simplifies things a _lot_). However that also depends on a few changes to bumblebee as well. Hence, would you be willing to upload the latest bumblebee + primus code from upstream's git repos (rather than the current stable bumblebee 3.1 release)? (fwiw primus has never really seen a formal 'stable' release, so it doesn't really matter for primus) As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... There's also the issue that Nvidia Optimus is a feature included only with Intel+Nvidia AFAIK, hence bbswitch+bumblebee+primus is really only useful on i386 and amd64 anyways. Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBmxZJcZMgfqUE7rTrLwN=3+aV=KTW_44BZx2a=y2l...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/commit/f95d06289f3fac202a6888b2d36f639e527c3f96 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbyutvyh1udyxze7_3_kcntmgvm81yfydhjrrst-dv...@mail.gmail.com
Bug#673426: RFP: virtualgl -- Toolkit for displaying OpenGL applications to thin clients
retitle 673426 ITP: virtualgl -- Toolkit for displaying OpenGL applications to thin clients submitter 673426 ! thanks It looks like libjpeg-turbo recently made it into the NEW queue [1]. There shouldn't be anything blocking virtualgl from being uploaded into Debian now; I'll take a stab at it once libjpeg-turbo is accepted into Debian. Regards, Vincent [1] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbgifmpne0g7b-76wtfpjs2l+2o5rqd3bdo57yphsj...@mail.gmail.com
Bug#673424: bbswitch packaging
Hi, First off, thanks for the bbswitch upload! On Sat, Mar 23, 2013 at 2:22 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Wednesday 20 March 2013 03:39 PM, Vincent Cheng wrote: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bumblebee_3.1-1.dsc In debian/bumblebee.preinst: it states: If you are a novice, you are recommended to reinstall Ubuntu. Upstream plans to drop that preinst file soon, since the old bumblebee/debumblebee are obsolete anyways. Is this allowed by the Debian packaging guidelines? Policy doesn't forbid it. Sharing is good but this is misleading both the product and brand. Derivatives are supposed to sync to the Debian archive and generate a delta. Typically the delta will be distro name changes et cetera. By adding derivative names (in this case Ubuntu) right into its pure package, this will create utter confusion. I'd urge you to package with only Debian in mind and let the derivatives handle it with a small delta. I see no harm in trying to make my package compatible with both Debian and Ubuntu, as long as the changes are not overly obtrusive and don't break anything in Debian. I'm actually of the opinion that it's best to minimize diffs between Debian and Ubuntu whenever possible, and I aim to do that with all the packages I maintain. Forcing derivatives to maintain deltas benefits nobody; we should encourage maintainers to forward as much work upstream as possible, and that goes for Ubuntu's relationship with Debian as well. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBCgemORKrKRxX26gDFs-F25sNbfdwOJ6WT=7z2sps...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
[Whoops, hit reply instead of reply to all. It's gmail's fault.] On Sat, Mar 23, 2013 at 3:24 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Saturday 23 March 2013 03:02 PM, Vincent Cheng wrote: I see no harm in trying to make my package compatible with both Debian and Ubuntu, as long as the changes are not overly obtrusive and don't break anything in Debian. I'm actually of the opinion that it's best to minimize diffs between Debian and Ubuntu whenever possible, and I aim to do that with all the packages I maintain. Forcing derivatives to maintain deltas benefits nobody; we should encourage maintainers to forward as much work upstream as possible, and that goes for Ubuntu's relationship with Debian as well. I can understand the intent but then it will become a never ending story. Which derivative will you stop at? It ends at Debian and Ubuntu. The one major difference that is the root cause of all the Debian/Ubuntu-specific sections in bumblebee's packaging is how differently the proprietary nvidia driver is packaged (if that were fixed one day, there'd be no need for all the derivative specific stuff). No Debian/Ubuntu derivatives use a different packaging scheme for the Nvidia proprietary driver, except those who suggest directly downloading it from Nvidia's website (which we don't support). Sooner or later, your packaging rules end up being: if debian: elif derivative1: elif derivative2: elif . Combining the efforts should mean working on a common base. Not accommodating multiple bases this way. We are working on a common base. I'm working with upstream to merge all the Debian-specific changes, so that we can all pull from the same source each time there's a new upstream release without me having to put as much work to merge everything. The current packaging (which Aron started) was based off of upstream's PPA, and so far it looks like upstream is receptive to our changes, so we can continue basing our work off of upstream's PPA for future releases. Hence, less duplicate work for us in Debian. Diverging the packaging must have good reasons; at least it brings in the flexibility and the speed. In this case, the best example is the nvidia packaging. I still don't see convincing rationale for us to diverge the bumblebee + primus packaging from the work that upstream have done, or to break compatibility between Debian and Ubuntu. Like I said in the previous email, I haven't seen a guideline on this topic. But from what I've observed in different teams, none of them package this way. I haven't seen any guidelines either. But I don't think I'm the only one who's actively trying to accomodate both Debian and Ubuntu; e.g. I've seen blog posts where DDs have demonstrated how to merge differences in Debian and Ubuntu in the packaging scripts (see Raphael Hertzog's explanation on how to generate different sets of dependencies for Debian and Ubuntu [1]), or e.g. the Ubuntu Games team folding into the Debian Games team to collaborate together (but to be fair, I don't think there was much of an Ubuntu Games team to begin with...). Regards, Vincent [1] http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAZJNPH0Db598YSqe_w6J7Z4pjDKBDVV3kpDLB5=r5...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi, On Sat, Mar 23, 2013 at 10:10 AM, Ritesh Raj Sarraf r...@researchut.com wrote: As much as I want and will use bumblebee, I do not agree with the justification. Let's just disagree. :-) You sponsor the packages bumblebee and primus so that it gets in the queue. Fair enough. Regardless, thanks for taking the time to review and upload bbswitch! You're welcome to work on the bbswitch/bumblebee/primus packaging if you still want to, but I ask that you do not revert the changes that I've made for compatibility with Ubuntu (or at least, not without any consensus first). Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tCmLFbiPCT8dF1j+W+fprer0jmaWCn0KnAn=ow2rpr...@mail.gmail.com
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 11:01 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Thursday 21 March 2013 10:34 PM, Vincent Cheng wrote: NEWS is already installed by dh_installdocs. But if you want to use dh_installchangelogs for that instead, I'm fine with that; do you want me to remove debian/docs as well then? I don't see the point of having duplicate copies. Yes. Please. The upstream NEWS file has nothing but the changelog. And also, the concept of README.Debian and NEWS.Debian are specific to Debian, afaik. Done. * bbswitch.c source file has no copyright header. It is good practice to have upstream's copyright declaration in each file. It's been added as of bbswitch 0.6. I don't see it on github. The MODULE_AUTHOR has the name but without the copyright header it is unclear who all contributed to it. This is no big deal. I will upload otherwise also. It is just FYI. Oops, I thought you meant the license header. Fair enough, I'll make a note to ask upstream about that. * bbswitch does not Recommend / Suggest bumblebee package. Is it intentional? Is bbswitch useful all alone on its own? Well, bbswitch should work fine on its own for users who don't want to use their discrete nvidia gpu, and just want power savings (by turning off the nvidia card with the bbswitch kernel module). Suggesting bumblebee sounds like a good idea though. Thanks. I will pull back your changes soon after dinner. And hopefully will upload it. :-) Done. Please feel free to upload bbswitch whenever you want. I have a few more last-minute changes for bumblebee+primus in response to feedback from upstream, but by the time you read this, I should've already committed them to the git repo for you to review. :) Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbdmy-b+yuvnt01+_3l_94lzpgtgkt5x4mbujnq4bu...@mail.gmail.com
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 6:35 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Wednesday 20 March 2013 03:39 PM, Vincent Cheng wrote: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bbswitch_0.6-1.dsc Here's some feedback for package bbswitch. * Upstream changelog is not shipped. Lintian warns about it. Good to have. I have fixed it and will send you the patch. You add it to the repo for me. Meanwhile I'll raise a request to add me to pkg-nvidia. NEWS is already installed by dh_installdocs. But if you want to use dh_installchangelogs for that instead, I'm fine with that; do you want me to remove debian/docs as well then? I don't see the point of having duplicate copies. * bbswitch.c source file has no copyright header. It is good practice to have upstream's copyright declaration in each file. It's been added as of bbswitch 0.6. * bbswitch does not Recommend / Suggest bumblebee package. Is it intentional? Is bbswitch useful all alone on its own? Well, bbswitch should work fine on its own for users who don't want to use their discrete nvidia gpu, and just want power savings (by turning off the nvidia card with the bbswitch kernel module). Suggesting bumblebee sounds like a good idea though. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tavxjymj-fdsqpp5r6+-rwr4y0sf4fmz__eulewfyk...@mail.gmail.com
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 10:39 AM, Aron Xu a...@debian.org wrote: It's very much appreciated if you can help on sponsoring, as my personal time isn't very abundant recently so it could be a quite long delay waiting my uploads... But I'll keep an eye on the package and responded as soon as I can. Ok, I think I've (finally) gotten everything dealt with, including the conffile issue (I ended up deciding to use the rest of Ralf's patch, and prepared a pull request upstream for all my changes [1]). Tested the packages and they work for me, so Aron/Ritesh, if one of you could review and upload them, that'd be great, thanks! http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bbswitch_0.6-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/primus_0~20130225-1.dsc (or fetch the latest from the git repos) Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB3fn_RGa=doMLb=w_CL3cAvoGRp6mvrK3=afhkpvo...@mail.gmail.com
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 3:06 AM, Ralf Jung p...@ralfj.de wrote: Hi, I suppose a better way of explaining why watching /proc/acpi/bbswitch isn't reliable is by referencing the differences between how the virtualgl and primus backends work. Virtualgl will always cause the secondary X server to be spawned (everything is rendered on the secondary X server before being displayed on the primary X server), whereas primus will only offload glx calls to bumblebee, thus the secondary X server will only start up when you run some sort of opengl application with primus. That means that optirun bash or optirun xterm will invariably turn on the secondary X server and the nvidia gpu, whereas primusrun bash or primusrun xterm (or some other application that doesn't use any glx calls) will not. However, if primusrun is invoked via optirun, then the second Xserver is spawned immediately - optirun itself does that before launching primusrun. Ah, I was unaware that optirun would spawn a secondary X server immediately regardless of whether the virtualgl or the primus backend is used. That's certainly different from what primusrun alone seems to do (spawn secondary X server only when needed, i.e. when glx calls are passed along to the nvidia gpu). In this scenario, primusrun has the advantage of keeping the second Xserver alive even if the program forks away, since primus is injected in each sub-process which is launched, while optirun+virtualgl monitor only the initially executed process. Yep, no need for that optirun bash workaround anymore. :) Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB=fmdh2ndea1oxrxefaypr45g7hrts10jufgqktdn...@mail.gmail.com
Bug#673424: bbswitch packaging
On Sun, Mar 17, 2013 at 9:25 AM, Ritesh Raj Sarraf r...@researchut.com wrote:
On Thursday 28 February 2013 11:16 AM, Ritesh Raj Sarraf wrote:
Installed, rebooted and everything seems to be working fine. This is
on the following platform:
rrs@zan:~$ uname -a
Linux zan 3.7-trunk-amd64 #1 SMP Debian 3.7.8-1~experimental.1 x86_64
GNU/Linux
rrs@zan:~$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [Quadro
K1000M] (rev ff)
PS: bumblebee 3.1 is supposed to have support for primus which I will
test once it can be built.
I pulled in your changes today and built primus. It is playing well with
my setup. Bumblebee is able to apply the power savings when
optirun/primusrun is not in use.
I wasn't actually done with primus' packaging; for some reason I kept
on getting a strange error (primus: fatal: failed to open secondary X
display) every time I tried running primusrun, even though it works
with the optirun+virtualgl backend, so I'm surprised that it worked
for you. That prompted me to dig deeper to find out what was causing
the issue for me; it turns out that, for whatever reason, reverting
one of my previous changes (overriding CXXFLAGS with dpkg-buildflags'
default build flags) fixed the problem for me, although I'm still
unsure why build hardening flags would've been the root cause. Oh
well...
I did have to uncomment the following in primusrun to make it work.
# Mesa drivers need a few symbols to be visible
export PRIMUS_LOAD_GLOBAL=${PRIMUS_LOAD_GLOBAL:-'libglapi.so.0'}
Please pull in my latest commits and test primusrun without
uncommenting the above line. The primusrun wrapper script should still
work correctly.
The NEW queue is big already and there's very little progress (has to do
with the freeze). But you would want to push primus now for review.
Agreed, at this point I think bumblebee and primus are ready for
review (bbswitch is already in the NEW queue and I'm happy with it
as-is). If you're offering to review the package and/or sponsor it,
thanks in advance! And feel free to make changes directly in the git
repo if you want to change anything. :)
(Aron, if you have a bit of time to spare, could you also take a look
at the changes I've made to bumblebee + primus?)
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caczd_tbagovkm1lxpa3gbddwiydcwkb7opmvganbdv3tvbh...@mail.gmail.com
Bug#659440: Patch for bumblebee package
Hi, First off, sorry for the delayed response... On Thu, Mar 7, 2013 at 1:32 AM, Ralf Jung p...@ralfj.de wrote: Hi, attached is a patch for the bumblebee package to properly handle the configuration files stored in /etc/bumblebee. For some reason, the package used to not ship these files, but instead copy them in postinst, which means users would not be prompted about changes in the default configuration, nor obtain an updated configuration if they did not change the file. I noticed this earlier too, but I was unsure whether there was a specific reason upstream decided not to use conffiles for some of the configuration files in /etc/bumblebee. That's something I plan on asking the upstream PPA maintainers, but for now I'm somewhat hesitant to change it... I also simplieifed debian/rules a bit in favour of using debian/bumblebee.install to give additional files which are included in the package. The bash-completion file is installed by make install, so there's no need to do that again. Thanks, applied this part of your patch to the git repo. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tDkOi75fS4q_PSqaY3vJAWYLbQr6NK2ZJZm0mV=g3h...@mail.gmail.com
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 12:22 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Monday 18 March 2013 11:44 AM, Vincent Cheng wrote: I wasn't actually done with primus' packaging; for some reason I kept on getting a strange error (primus: fatal: failed to open secondary X display) every time I tried running primusrun, even though it works with the optirun+virtualgl backend, so I'm surprised that it worked for you. That prompted me to dig deeper to find out what was causing the issue for me; it turns out that, for whatever reason, reverting one of my previous changes (overriding CXXFLAGS with dpkg-buildflags' default build flags) fixed the problem for me, although I'm still unsure why build hardening flags would've been the root cause. Oh well... I already purged the virtualgl packages, so I am pretty sure that it is using the primus backend. Please pull in my latest commits and test primusrun without uncommenting the above line. The primusrun wrapper script should still work correctly. Yes. It works but there's a catch. See below. The NEW queue is big already and there's very little progress (has to do with the freeze). But you would want to push primus now for review. Agreed, at this point I think bumblebee and primus are ready for review (bbswitch is already in the NEW queue and I'm happy with it as-is). If you're offering to review the package and/or sponsor it, thanks in advance! And feel free to make changes directly in the git repo if you want to change anything. :) I am too new and haven't investigated much about this whole dual graphics display. But I am willing to sponsor if there are no takers. Thanks! I'll take you up on your sponsorship offer if I don't hear back from Aron in a while. :) By the way, with bumblebee + primus installed, you still will want to recommend users to call apps with the optirun interface. primus just sets some library variables and calls the application. The application is never run on the discrete nvidia card. Errr, no. As I understand it, that's exactly what primus is supposed to do (offload glx calls to nvidia card, hence the purpose of adding primus' own libGL to LD_LIBRARY_PATH). optirun just makes it convenient to switch between virtualgl or primus through a configuration setting. Try testing with: # apt-get install mesa-utils $ optirun -b primus glxgears -info $ primusrun glxgears -info They should give you the same results. Refer to the following screenshots [1] [2]. Where as, if you run optirun (or -b primus), you will notice it running on nvidia. Easiest way to verify this is to watch /proc/acpi/bbswitch when using either of the interface. That's not reliable way of verifying this because you can force the secondary X server to be permanently on, and running on your nvidia GPU. It's as simple as s/KeepUnusedXServer=false/KeepUnusedXServer=true/ in /etc/bumblebee/bumblebee.conf, or optirun bash. Regards, Vincent [1] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png [2] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_ta0zp6clpqsjizo5xfptftverc89y8e3tpa4xbldfl...@mail.gmail.com
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 6:50 AM, Ritesh Raj Sarraf r...@researchut.com wrote:
On Monday 18 March 2013 01:15 PM, Vincent Cheng wrote:
Try testing with:
# apt-get install mesa-utils
$ optirun -b primus glxgears -info
$ primusrun glxgears -info
Okay!! I got uniform results but I had to again uncomment the following
line. Without it, it was running on the Intel card.
# Need functions from primus libGL to take precedence
export LD_LIBRARY_PATH=${PRIMUS_libGL}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
That line was already uncommented out in the script shipped by the package...
Where as, if you run optirun (or -b primus), you will notice it running
on nvidia.
Easiest way to verify this is to watch /proc/acpi/bbswitch when using
either of the interface.
That's not reliable way of verifying this because you can force the
secondary X server to be permanently on, and running on your nvidia
GPU. It's as simple as
s/KeepUnusedXServer=false/KeepUnusedXServer=true/ in
/etc/bumblebee/bumblebee.conf, or optirun bash.
Yes. But I have ensure always that I review the config file. And in my
opinion, the defaults should be KeepUnusedXServer=false
I suppose a better way of explaining why watching /proc/acpi/bbswitch
isn't reliable is by referencing the differences between how the
virtualgl and primus backends work. Virtualgl will always cause the
secondary X server to be spawned (everything is rendered on the
secondary X server before being displayed on the primary X server),
whereas primus will only offload glx calls to bumblebee, thus the
secondary X server will only start up when you run some sort of opengl
application with primus. That means that optirun bash or optirun
xterm will invariably turn on the secondary X server and the nvidia
gpu, whereas primusrun bash or primusrun xterm (or some other
application that doesn't use any glx calls) will not.
I will try to update all the packages now and see the final results.
Looks like you guys have pushed some updates today.
Please do test out my changes, but also please don't upload the
packages yet. I want to sort out the conffiles issue [1] first...
Regards,
Vincent
[1]
http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2013-March/008565.html
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CACZd_tDkGoj=_rRN3XEA6H3BweK6yk5TkU7hnVaUwShoa+g=b...@mail.gmail.com
Bug#699726: ITP: bijiben -- intuitive note editor integrated with GNOME 3
Just a quick status update: bijiben's packaging is now in collab-maint [1] if anyone's interested in it. Currently not yet uploaded because the tracker-sparql version in experimental is too old. [1] http://anonscm.debian.org/viewvc/collab-maint/deb-maint/bijiben/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbe_9drc_4uc+4jv2wacbtxb7noyn42myssahsdpvv...@mail.gmail.com
Bug#701157: ITP: steam-nonfree --- Installer for the Steam software distribution service
On Fri, Feb 22, 2013 at 12:41 AM, Boris Pek tehnic...@yandex.ua wrote: Package: wnpp Severity: wishlist Owner: Boris Pek tehnic...@mail.ru X-Debbugs-Cc: debian-devel-ga...@lists.debian.org * Package name: steam-nonfree Version : 1.0.0.28 Upstream Author : Valve Corporation li...@steampowered.com * URL : http://www.steampowered.com/ * License : Steam-Install-Agreement Description : Installer for the Steam software distribution service Steam is a software distribution service with an online store, automated installation, automatic updates, achievements, SteamCloud synchronized savegame and screenshot functionality, and many social features. License of Steam allows the distribution of unmodified files. (See attachment) Discussion in debian-devel-games mailing list: http://lists.debian.org/debian-devel-games/2013/02/threads.html#00028 FYI, Michael Gilbert has already packaged it and uploaded it to NEW: http://ftp-master.debian.org/new/steam_1.0.0.28-1.html Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tdsv1cfe+ph1jupxtszdwpmiyyjslv4abfg4xrhd-4...@mail.gmail.com
Bug#659440: bumblebee packaging
On Fri, Feb 15, 2013 at 7:20 AM, Aron Xu happyaron...@gmail.com wrote: Hi, On Tue, Jan 29, 2013 at 3:00 PM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, have you contacted upstream and asked to merge our work with their PPA packaging? I want to try to push as much of our work upstream to avoid duplicate work and potential oversights on our part...also, I suppose maybe some of their Ubuntu PPA packagers might be able to help with upstart. I'll go about preparing a merge request on Github if you aren't planning on doing so yourself. Not yet, while my first packaging was based on their PPA, though they only installed upstart init scripts in their PPA. Please go ahead with the merge request. Ok, I'll get around to it once I think about how I'm going to approach primus' packaging (refer to that other email I sent you for details). Now that bumblebee is taken care of, I've (finally) uploaded my primus packaging, to collab-maint for now (but am open to moving it into pkg-nvidia) [1]. Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=collab-maint/primus.git I'm okay for either collab-maint or pkg-nvidia, so it's up to your choice, :) Well...I feel inclined to pick pkg-nvidia just so we don't have to have a long list of people to cc: every time something related to primus' packaging is discussed. ;) I'll move the repository over from collab-maint to pkg-nvidia tomorrow then. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tC_=U_mZAfhatRgRS1E-Dvb4Qfgv8y=8inhohb7r4f...@mail.gmail.com
Bug#700044: ITP: bbswitch-dkms -- Kernel module for toggling power of nVidia Optimus
forcemerge 673424 700044 thanks On Thu, Feb 7, 2013 at 12:12 PM, Maximiliano Curia m...@debian.org wrote: Package: wnpp Severity: wishlist Owner: Maximiliano Curia m...@debian.org * Package name: bbswitch-dkms Version : 0.5-1 Upstream Author : Peter Lekensteyn lekenst...@gmail.com * URL : https://github.com/Bumblebee-Project/bbswitch * License : GPL Programming Lang: C Description : Kernel module for toggling power of nVidia Optimus bbswitch is a kernel module which allows turning the power on or off for nVidia Optimus video cards. . Card status can be queried and modified during normal usage or at boot time. bbswitch is currently sitting in the NEW queue [1]. Regards, Vincent [1] http://ftp-master.debian.org/new/bbswitch_0.5-1.html -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tCFxooRpgje=k0z-s+9zyjb5mrcqhvdib4o3jopjjf...@mail.gmail.com
Bug#699726: ITP: bijiben -- intuitive note editor integrated with GNOME 3
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: bijiben Version : 3.7.5 Upstream Author : Pierre-Yves Luyten p...@luyten.fr * URL : https://live.gnome.org/Bijiben * License : GPL-3+ Programming Lang: C Description : intuitive note editor integrated with GNOME 3 Bijiben is a note editor that is designed to be intuitive and easy to use, and well integrated with GNOME 3. (Yes, I know we already have Tomboy and Gnote, but Bijiben comes closest to implementing GNOME's Notes design [1].) [1] https://live.gnome.org/Design/Apps/Notes -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130204054730.16023.3801.reportbug@vincent-tlaptop
Bug#659440: bumblebee packaging
On Wed, Jan 23, 2013 at 2:24 AM, Vincent Cheng vincentc1...@gmail.com wrote: [...] Anyways, right now I'm hitting a strange bug with the packages I built; dpkg just seems to hang while installing bumblebee and bumblebee-nvidia, i.e.: $ sudo dpkg -i bumblebee_3.0.1-1_amd64.deb bumblebee-nvidia_3.0.1-1_amd64.deb (Reading database ... 398188 files and directories currently installed.) Preparing to replace bumblebee 3.0.1-1 (using bumblebee_3.0.1-1_amd64.deb) ... [ ok ] Stopping Bumblebee daemon: bumblebeed. Unpacking replacement bumblebee ... Preparing to replace bumblebee-nvidia 3.0.1-1 (using bumblebee-nvidia_3.0.1-1_amd64.deb) ... Unpacking replacement bumblebee-nvidia ... Setting up bumblebee (3.0.1-1) ... Installing new version of config file /etc/init.d/bumblebeed ... update-initramfs: deferring update (trigger activated) ...seems to get stuck here It turns out that the problem isn't caused by the postinst script. I tried stripping out portions of it piece by piece (starting with the conffile handling/dpkg-maintscript-helper snippets), but nothing helped. Then I took a look at what should've appeared right afterwards if dpkg didn't get stuck somehow: snip Setting up bumblebee (3.0.1-1) ... Adding members from group(s) 'adm sudo admin' to 'bumblebee': update-initramfs: deferring update (trigger activated) [ ok ] Starting Bumblebee daemon: bumblebeed. Ah, bumblebee's init script... A 3-way comparison later between the distro-agnostic init script provided upstream, the one provided by suwako.nomanga.net, and the one currently in the pkg-nvidia git repo (presumably taken from a dh-make template?), and it turns out that this is what was missing: -DAEMON_ARGS=--use-syslog +DAEMON_ARGS=--daemon --use-syslog And the package installs fine now. :) Aron, have you contacted upstream and asked to merge our work with their PPA packaging? I want to try to push as much of our work upstream to avoid duplicate work and potential oversights on our part...also, I suppose maybe some of their Ubuntu PPA packagers might be able to help with upstart. I'll go about preparing a merge request on Github if you aren't planning on doing so yourself. Now that bumblebee is taken care of, I've (finally) uploaded my primus packaging, to collab-maint for now (but am open to moving it into pkg-nvidia) [1]. Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=collab-maint/primus.git -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_td75hnova+qr0ppqxhoiwmzo9ybnniad02deklzsec...@mail.gmail.com
Bug#692597: bumblebee packaging
On Mon, Jan 21, 2013 at 1:51 AM, Andreas Beckmann deb...@abeckmann.de wrote:
On 2013-01-21 10:12, Vincent Cheng wrote:
On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote:
I've made some progress on bumblebee and pushed to pkg-nvidia repo:
I've made a number of small changes to take into account certain
differences between Debian and Ubuntu's packaging of nvidia's
proprietary drivers [1][2] and added an udev rule to fix a bug [3].
Nice too see some progress :-)
Are there any problems you encounter with the nvidia driver packaging in
Debian? Please also test with nvidia-kernel-common and glx-alternative-*
from experimental (they change the kernel module blacklist handling to
be controlled with the glx alternatives, a update-initramfs call may be
needed in addition to update-alternatives, but therefore you can disable
the blacklist without manually doing rm or dpkg --purge).
I have no problem with bumblebee and the current versions of
nvidia-kernel-common and glx-alternative-{mesa,nvidia} in
experimental; I've been tracking experimental for a while to get the
latest nvidia driver releases anyways.
Regardless of how glx-alternatives handles module blacklisting,
debian/bumblebee.modprobe (installed by bumblebee's packaging as
/etc/modprobe.d/bumblebee.conf) actually blacklists both nouveau and
nvidia, since the discrete nvidia card is powered down when not in use
and bbswitch loads and unloads the desired module on demand (when not
in use, neither module is loaded).
One of the goals of the current packaging is usability in live systems -
having all the proprietary drivers co-installable and allow them to be
installed but deactivated, so that some (yet to be written) utility
could detect hardware, switch alternatives, and create X config.
It would be nice if bumblebee would somehow integrate in this.
(Disclaimer: I don't do anything -live myself.)
I've never tried running bumblebee + nvidia drivers on a live system
before, but I think this should be possible, so long as nouveau can be
unloaded without having to reboot (I suppose since i915 is driving the
on-board graphics card and the display, that this is possible?).
Vincent
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CACZd_tCEUiv+A=3lyd1xe345sly6q21vx4h1fktsrbwxv6+...@mail.gmail.com
Bug#659440: bumblebee packaging
On Mon, Jan 21, 2013 at 1:36 AM, Aron Xu happyaron...@gmail.com wrote: Hi Vincent, On Mon, Jan 21, 2013 at 5:12 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi Aron, On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote: Hi, I've made some progress on bumblebee and pushed to pkg-nvidia repo: http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git But because it's late here I can't test it now, if anyone can try it please let me know your results, thanks! I've made a number of small changes to take into account certain differences between Debian and Ubuntu's packaging of nvidia's proprietary drivers [1][2] and added an udev rule to fix a bug [3]. Also cleaned up a few lintian tags (patch headers, and added a spiffy new watch file). I haven't actually tried installing those packages yet, but I'll try to get to that asap (on a slightly unrelated note, I'll also try to clean up my primus packaging a bit and get that uploaded too). Thanks for your work, I've tested my previous version on Debian Wheezy with a T420 Laptop, and it works as expected, using sysvinit and systemd, 3.2 and 3.7 kernels, all of them are ok. I tried to install my version of bbswitch and bumblebee on Ubuntu, but it appears that upstart needs more tuning, which I haven't worked on yet. If you have interest in it please have a try. Assuming that you're also using the proprietary nvidia drivers, I'm a bit surprised that your previous version (before I added my commits to the git repo, right?) of bumblebee's packaging works on your Debian laptop. The most important difference between the PPA and Igor's packaging is in bumblebee-nvidia's postinst: PPA: # update-alternatives --set $arch_gl_conf /usr/lib/$arch/mesa/ld.so.conf Igor's debian bumblebee repo (suwako.nomanga.net): # update-alternatives --set glx /usr/lib/mesa-diverted Assuming you haven't manually run update-alternatives to divert the glx symlink from /usr/lib/nvidia - /usr/lib/mesa-diverted (/usr/lib/nvidia has a higher priority than mesa-diverted), which for the record is also mentioned on the Bumblebee page of Debian's wiki [1], your intel graphics card would be trying to use nvidia's libGL instead of mesa's implementation, and you'd lose 3D acceleration. Debian's alternatives system doesn't have $arch_gl_conf, so the Ubuntu PPA's postinst (and your previous packaging) would fail to correctly divert libGL in Debian. (Unless I'm horribly mistaken and/or overlooked something in your packaging?) Just curious, what's the output of sudo update-alternatives --display glx and glxinfo on your laptop? Anyways, right now I'm hitting a strange bug with the packages I built; dpkg just seems to hang while installing bumblebee and bumblebee-nvidia, i.e.: $ sudo dpkg -i bumblebee_3.0.1-1_amd64.deb bumblebee-nvidia_3.0.1-1_amd64.deb (Reading database ... 398188 files and directories currently installed.) Preparing to replace bumblebee 3.0.1-1 (using bumblebee_3.0.1-1_amd64.deb) ... [ ok ] Stopping Bumblebee daemon: bumblebeed. Unpacking replacement bumblebee ... Preparing to replace bumblebee-nvidia 3.0.1-1 (using bumblebee-nvidia_3.0.1-1_amd64.deb) ... Unpacking replacement bumblebee-nvidia ... Setting up bumblebee (3.0.1-1) ... Installing new version of config file /etc/init.d/bumblebeed ... update-initramfs: deferring update (trigger activated) ...seems to get stuck here (Reproducible with the packaging after I committed my changes, and with only your changes instead.) Poking around with ps tells me that the show stopper is /bin/sh /var/lib/dpkg/info/bumblebee.postinst configure 3.0.1-1, hence something about bumblebee's postinst script is causing me some trouble, but then again Igor's Debian bumblebee packages work fine: $ sudo apt-get install bumblebee bumblebee-nvidia Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: bumblebee bumblebee-nvidia 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/62.0 kB of archives. After this operation, 246 kB of additional disk space will be used. Retrieving bug reports... Done Parsing Found/Fixed information... Done Selecting previously unselected package bumblebee. (Reading database ... 398161 files and directories currently installed.) Unpacking bumblebee (from .../bumblebee_3.0.1-1_amd64.deb) ... Selecting previously unselected package bumblebee-nvidia. Unpacking bumblebee-nvidia (from .../bumblebee-nvidia_3.0.1-1_all.deb) ... Processing triggers for man-db ... Setting up bumblebee (3.0.1-1) ... [ ok ] Starting Bumblebee daemon: bumblebeed. Setting up bumblebee-nvidia (3.0.1-1) ... update-alternatives: using /usr/lib/mesa-diverted to provide /usr/lib/glx (glx) in manual mode $ I'll take another look at this tomorrow, but for now I just want to go to bed. :) Regards, Vincent [1] http://wiki.debian.org/Bumblebee#Driver_choice -- To UNSUBSCRIBE, email to debian-wnpp-requ
Bug#659440: bumblebee packaging
Hi Aron, On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote: Hi, I've made some progress on bumblebee and pushed to pkg-nvidia repo: http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git But because it's late here I can't test it now, if anyone can try it please let me know your results, thanks! I've made a number of small changes to take into account certain differences between Debian and Ubuntu's packaging of nvidia's proprietary drivers [1][2] and added an udev rule to fix a bug [3]. Also cleaned up a few lintian tags (patch headers, and added a spiffy new watch file). I haven't actually tried installing those packages yet, but I'll try to get to that asap (on a slightly unrelated note, I'll also try to clean up my primus packaging a bit and get that uploaded too). Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=commitdiff;h=9544a02384389d14a41af6f0e5e3f0d4146f8f73 [2] http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=commitdiff;h=7f51942a698ab09009b17a528418bbd6a3dfc78b [3] https://github.com/Bumblebee-Project/Bumblebee/issues/144 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tDObMGjj027x-dbs+qNdejo-JUW=htfagwn79-e9oj...@mail.gmail.com
Bug#692597: Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Sun, Jan 6, 2013 at 12:33 AM, Mathieu Malaterre ma...@debian.org wrote: On Sun, Jan 6, 2013 at 2:41 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Thu, Jan 3, 2013 at 11:53 PM, Mathieu Malaterre ma...@debian.org wrote: On Thu, Jan 3, 2013 at 10:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! Since both packages are related to NVidia technologies, why not maintain them under the Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org group ? See: http://qa.debian.org/developer.php?login=pkg-nvidia-de...@lists.alioth.debian.org 2cts, I'm indifferent to maintaining the set of packages that bumblebee requires either within or outside of pkg-nvidia. On one hand, virtualgl/primus is only being considered in Debian right now for bumblebee support, but these technologies are not specifically tied to Nvidia. Then again, bumblebee and co. will only be necessary with the proprietary nvidia drivers once prime/dma-buf support for nouveau is fully implemented and mature (I'm unsure about what the current status of optimus support with the free drivers are, at this moment). I'll hold off on uploading my primus packaging until we come to some sort of consensus... Please dont. My suggestion to use the pkg-nvidia-devel umbrella group was simply a mean of going thing going, not stopping them. I work within other umbrealla group and this help in situations such as (p-n-d makes it as easy chanel for discussion): - request DD upload from a DM - discussion on p-n-d@d.o on complex dependencies for package. If your package is a leaf in the dependency tree, then this does not apply to you. I generally agree that maintaining packages in a team is better than not doing so, when there are multiple people willing to work on the package. For primus specifically however, I'm still not quite sure which approach everyone would prefer; Aron has already said that he thinks that primus should be maintained outside the team, and I don't think anyone who's currently in the pkg-nvidia team (Russ/Andreas?) has commented on whether or not they'd like to have primus maintained within the team. Being able to use pkg-nvidia-devel@lists.a.d.o rather than having to setup another mailing list is certainly very convenient though. If you feel confidant, then please upload as-is. I'm just a DM, so I'll need a sponsor once the package is fit for the archives. (I've worked with Aron on a number of other packages before, so presumably he'd be willing to sponsor my package, regardless of whether primus ends up being team-maintained or not.) How about this: I'll upload my work to collab-maint for now, and if we decide later that we do in fact want primus maintained in pkg-nvidia, we could always just switch over. :) Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tdywrxb7hrc1a2z6a+wwvmxppk6jt47fkj-wafzikb...@mail.gmail.com
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Thu, Jan 3, 2013 at 1:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! I'd be glad to help out and co-maintain bumblebee and co. with you (and that goes for everyone who's following along with this bug report). I've just gotten commit access for pkg-nvidia's repositories and will upload the work I've done on primus later tonight. Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tC2MSmGKWW05DZ6RHUau=+ak6FbSXcw+w7=f_5i+bm...@mail.gmail.com
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Thu, Jan 3, 2013 at 11:53 PM, Mathieu Malaterre ma...@debian.org wrote: On Thu, Jan 3, 2013 at 10:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! Since both packages are related to NVidia technologies, why not maintain them under the Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org group ? See: http://qa.debian.org/developer.php?login=pkg-nvidia-de...@lists.alioth.debian.org 2cts, I'm indifferent to maintaining the set of packages that bumblebee requires either within or outside of pkg-nvidia. On one hand, virtualgl/primus is only being considered in Debian right now for bumblebee support, but these technologies are not specifically tied to Nvidia. Then again, bumblebee and co. will only be necessary with the proprietary nvidia drivers once prime/dma-buf support for nouveau is fully implemented and mature (I'm unsure about what the current status of optimus support with the free drivers are, at this moment). I'll hold off on uploading my primus packaging until we come to some sort of consensus... Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tds-48fbc5dh3rado7ot6pnhhorr+cn8wmy0d_ytih...@mail.gmail.com
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbu9h3ozu2xppup5kyqkozx1kh8onxyprz6c25nmrr...@mail.gmail.com
Bug#693868: ITP: mailnag -- mail notification daemon for GNOME 3
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: mailnag Version : 0.4.4 Upstream Author : Patrick Ulbrich zul...@gmx.net * URL : https://github.com/pulb/mailnag * License : GPL-2+ Programming Lang: Python Description : mail notification daemon for GNOME 3 Mailnag checks POP3 and IMAP servers for new mail. When it finds new messsages, it creates a GNOME 3 notification that mentions sender and subject. (Not part of extended description: This is similar to mail-notification, except that it's not dead upstream and it's integrated nicely with GNOME shell) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121121090945.14168.82421.reportbug@vincent-tlaptop
Bug#523834:
On Tue, Nov 6, 2012 at 3:21 AM, Guest One theguest...@gmail.com wrote: Some news about inclusion of Naev in official Debian repositories? AFAIK no progress on this for a while, but feel free to check the games team's svn repo if you want to see what's done, and what's yet to be done; feel free to help out or takeover this ITP if you want. Personally, I don't have much time to spare at the moment, and introducing new packages during a freeze is low on my list of priorities. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tcvhwv5zvjlydskaisifwootsybxwwowgdjzvpd9hg...@mail.gmail.com
Bug#673584: ITA: nethack -- dungeon crawl game
retitle 673584 ITA: nethack -- dungeon crawl game owner 673584 ! thanks I'm willing to adopt this package and maintain it under the umbrella of the Debian Games team. I also currently maintain slashem (a variant of nethack), so taking care of nethack as well shouldn't be too much trouble. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tC+oGwa8agpPnz8xu+jviC=1gp6x9djasrewuymzoz...@mail.gmail.com
Bug#632654: ITA: tolua++ -- Extended tool to integrate C/C++ code with Lua
retitle 632654 ITA: tolua++ -- Extended tool to integrate C/C++ code with Lua owner 632654 ! thanks As this is one of the build dependencies of a package I maintain (conky), and since nobody else intends to adopt this, I'll do so myself. Regards, Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tdukk65vbqfbzhwm7epn+pqd9fioijd_ngqxyehr6r...@mail.gmail.com
Bug#594800: 0ad: Unused dependencies
On Thu, Apr 5, 2012 at 4:02 AM, Fabio Pedretti fabio@libero.it wrote: In the SVN there are some dependencies which are probably no longer needed: cmake (was used for nvtt), nasm and possibly others, look here for what's is needed currently: http://trac.wildfiregames.com/wiki/BuildInstructions#Linux Thanks! I've removed cmake, libalut-dev, libdevil-dev, libglew1.5-dev, libopenexr-dev, nasm, python, zip from 0ad's build-depends and can confirm that it still builds properly in a pbuilder chroot. Are there any other build dependencies that can still be removed? Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tarz+3ng16_h9xs+dkbkaawnrwthr_-0qws3q-fnzp...@mail.gmail.com
Bug#661458: ITA: supertux -- Classic 2D jump 'n run sidescroller with Tux
According to #535147, it looks like supertux has already been adopted by the Debian Games team (in experimental, at least). I'll just prepare updated packaging for supertux in unstable, then. Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAq_rfuwNvFt2D0p50sv=axywxybkswshwf4qnv_6f...@mail.gmail.com
Bug#661458: ITA: supertux -- Classic 2D jump 'n run sidescroller with Tux
I've prepared a lintian-clean, pbuilder-clean package, ready for upload; I'd greatly appreciate it if somebody could review and sponsor my packaging. Thanks in advance! http://mentors.debian.net/package/supertux $ dget http://mentors.debian.net/debian/pool/main/s/supertux/supertux_0.1.3-2.dsc Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tc17ead4v0s7xr+uzhzbeujs6+3kfgexar69ab_0dn...@mail.gmail.com
Bug#661458: O: supertux -- Classic 2D jump 'n run sidescroller with Tux
retitle 661458 ITA: supertux -- Classic 2D jump 'n run sidescroller with Tux owner 661458 vincentc1...@gmail.com thanks I'd be willing to adopt SuperTux under the umbrella of the Debian Games team. If anybody else in the team wants to be co-uploaders, that'd be great. :) Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB=otp3fq7cj4_ytj9rwikzdgqke6sdsmv5olsaph5...@mail.gmail.com
Bug#652954: ITP: logisim -- graphical tool for designing and simulating logic circuits
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: logisim Version : 2.7.1 Upstream Author : Carl Burch logi...@cburch.com * URL : http://ozark.hendrix.edu/~burch/logisim/ * License : GPL-2+ Programming Lang: Java Description : graphical tool for designing and simulating logic circuits Logisim is an educational tool for designing and simulating digital logic circuits. With its simple toolbar interface and simulation of circuits as you build them, it is simple enough to facilitate learning the most basic concepts related to logic circuits. With the capacity to build larger circuits from smaller subcircuits, and to draw bundles of wires with a single mouse drag, Logisim can be used (and is used) to design and simulate entire CPUs for educational purposes. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111222075149.25954.82280.reportbug@vincent-laptop
Bug#594800: embedded libraries
On Thu, Dec 8, 2011 at 5:11 AM, Fabio fabio@libero.it wrote: Now that enet is taken care of, I believe the only remaining embedded library is libmozjs/spidermonkey. In current SVN (will be in 0ad alpha 8) there is support for building against libmozjs185 (tested on Ubuntu). Dunno however if it will works with Debian libmozjs. Debian's libmozjs version is different from the standalone mozjs source package currently available in Ubuntu. I'll ask and see if it could possibly be backported to Debian; if not, do you know whether 0ad can currently build against a different version of mozjs? 0ad also provides a custom embedded copy of FCollada. There was some work on setting up a FCollada project, but it looks like it is abandoned now: http://www.wildfiregames.com/forum/index.php?showtopic=14539 https://github.com/fcolladaCE/fcolladaCE Then it is also using its patched version of premake4: http://www.wildfiregames.com/forum/index.php? showtopic=14173st=100p=226306#entry226306 I guess that means we'll be leaving fcollada and premake4 bundled along with 0ad's source for now. Lastly, also have a look at the Ubuntu packages available at: https://launchpad.net/~wfg/+archive/0ad.dev Ok, thanks! Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tb_bvfw4nbnamkpgn2cysv-o6b_twpem87mvwtyis7...@mail.gmail.com
Bug#580358: RFS: cherrytree
I've prepared a cherrytree package ready to be uploaded Debian; it is pbuilder and lintian -I --pedantic clean. I've already sent out a RFS request to debian-mentors@l.d.o, but I'm also throwing this out here in my ITP as well. $ dget http://mentors.debian.net/debian/pool/main/c/cherrytree/cherrytree_0.23.1-1.dsc Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBscZKCSS33vq-sAByMPm9Tea4s=ouzc5-pfcbj1kj...@mail.gmail.com
Bug#640167: RFS: openssn
Dear mentors, I am looking for a sponsor for my package openssn. * Package name: openssn Version : 0.7-1 Upstream Author : Jesse Smith jessefrgsm...@yahoo.ca * URL : http://openssn.sourceforge.net/ * License : GPL2 (code), CC0 (data) Section : games Description: modern submarine tactical simulator OpenSSN is a submarine simulation (subsim) which tries to emulate the behaviour of modern submarines. The player is placed in command of a submarine and is able to move about in a deep ocean environment. It builds those binary packages (which are lintian and pbuilder clean): openssn- modern submarine tactical simulator openssn-data - modern submarine tactical simulator (data) openssn-dbg - modern submarine tactical simulator (debug) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/openssn Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/openssn/openssn_0.7-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Vincent Cheng -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_taohzvrrcsqy3jjofncu-g9edrli2tcs09nrfy0ztc...@mail.gmail.com
Bug#594800: 0ad beta 6 packages
On Sun, Aug 14, 2011 at 2:46 AM, Paul Wise p...@debian.org wrote: On Sun, Aug 14, 2011 at 9:11 AM, Vincent Cheng wrote: I'll upload it to mentors.d.n later tonight or tomorrow if anyone wants to take a second look at it. Refreshed my 0ad package and uploaded it to mentors.d.n: $ dget http://mentors.debian.net/debian/pool/main/0/0ad/0ad_0+r09786-1.dsc Didn't review that yet and I probably won't get to it until late August since I will be travelling. but for some reason dput segfaulted halfway through That sounds like a python bug. You might want to enable core dumps on your system so that you can file bugs about random crashes. http://releases.wildfiregames.com/0ad-r09786-alpha-unix-data.tar.xz The upstream tarball contains a pre-built copy of the DejaVu font, please ask them to remove that. Likewise for the other font, that should be packaged separately from 0ad using the upstream project. It is perfectly acceptable for upstream to include pre-built fonts in their binary installers/packages for platforms with broken/missing repository/dependency systems but the source packages and VCS should not include non-source forms and should not contain embedded copies of other projects. http://www.gust.org.pl/projects/e-foundry/tex-gyre/pagella There doesn't appear be any suspicious metadata in the images. A couple of the images are pre-rendered text. I wonder which font they used and if it. IMO text should only be rendered at runtime since that enables i18n and ensure that any fonts used on Debian systems are DFSG-free. IMO the small versions of the icons should be removed and the scaling should happen either at runtime or buildtime. I think it would be nice to convert the images to vector so that the UI can scale to any resolution. The buttons dir contains only small versions, so I wonder if there is some source code missing there. There is a ZIP file in there too. It seems a bit rediculous to put a compressed file inside the already compressed tarball and even more rediculous to put such a file in a VCS (didn't look if it was there too). If I unpack the zip file I get a shitload of other stuff. I don't have time to review the whole thing right now, but based on find | xargs file there are some things that are not source code or not in standard, modifiable formats, which is what the source package should consist of. The font stuff inside it weird. IMO this should be replaced by vector fonts rendered at runtime. There are other images with pre-rendered text that possibly was rendered using non-free fonts. Also the ./public/art/LICENSE.txt file indicates that all the materials from CGTextures are missing their source form. I find it completely bizarre that they are using an Excel spreadsheet to store techtree info. Does the game really require a Excel file reading code?? Those xmb files look like binary versions of the corresponding xml files. These should be generated at build time not stored in the source tarball or VCS. There are some weird binary formats. One of them contained a string: God Knows, perhaps that should be replaced with God Knows WTF these files are and how to modify them ;) I wonder about the DDS files. They can be opened in GIMP with gimp-dds but their names seem to indicate that there are TGA files that are the source form of them. IMO the DDS files should be created at runtime/build time from their source TGA files, or the game should simply switch to using the TGA files. There are a bunch of pre-encoded Ogg files. I don't know what is the source but Ogg definitely is not it. There should be some sort of losslessly encoded audio or the project files for whatever DFSG-free program generated these files. There are two RAR files. RAR is a proprietary format that is not yet uncompressible only using software in Debian main. There is a free software decompressor implementation but it is not yet in Debian (#619602) and I haven't been able to compile it yet. Please ask upstream to not store these in the source package and not in the VCS either. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-games-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gs9p-xn8l4x5rx7wivz1zgfsgmqzby3bu-roh3zjv...@mail.gmail.com Thanks for the review; cc'ing Philip so that he can take a look at these issues and perhaps address them upstream. I believe the issues with pre-rendered text were discussed previously in the discussion following my first RFS posting, but most of these other issues you bring up haven't been discussed yet and are definitely worth bringing to upstream's attention. - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tCxuBzRncRvybS
Bug#594800: 0ad beta 6 packages
I'll upload it to mentors.d.n later tonight or tomorrow if anyone wants to take a second look at it. Refreshed my 0ad package and uploaded it to mentors.d.n: $ dget http://mentors.debian.net/debian/pool/main/0/0ad/0ad_0+r09786-1.dsc I was about to upload my 0ad-data package as well, but for some reason dput segfaulted halfway through, so for the moment I'll simply ask you to download the data tarball directly from upstream: http://releases.wildfiregames.com/0ad-r09786-alpha-unix-data.tar.xz My actual packaging for 0ad-data (the stuff under debian/) can be fetched with: $ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/0ad-data/ I'll try again and re-upload 0ad-data to mentors tomorrow; sorry for the inconvenience! 0ad and 0ad-data are both pbuilder clean, and the game runs fine, but they aren't lintian clean (I'll work on fixing this later), and as previously mentionned, there are issues with embedded libraries and whatnot, so it probably can't be uploaded to the Debian archive in its current state. - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBeVYFtqMyP24=_jzf3tcct49_fuecmcudcyoygda9...@mail.gmail.com
Bug#594800: 0ad beta 6 packages
On Sat, Aug 13, 2011 at 1:00 PM, Paul Wise p...@debian.org wrote: On Sat, Aug 13, 2011 at 9:22 PM, Joachim Breitner nome...@debian.org wrote: what is the state of the 0ad ITP? The newest package on mentors is beta 4, it would be nice to get updated packages there, even while they are made fit for the main archive. I don't think anything has changed since the RFS thread: http://lists.debian.org/debian-mentors/2011/04/threads.html#00021 Alpha 6 (there haven't been any beta releases yet) is now compatible with the version of enet in Debian sid (1.3), so that's one less thing to worry about. But I'm not sure if it's ready for another RFS. IIRC there were/are embedded library issues. Now that enet is taken care of, I believe the only remaining embedded library is libmozjs/spidermonkey. Probably it also needs an audit to see if it complies with DFSG item 2 along these guidelines: http://www.freedesktop.org/wiki/Games/Upstream#Source I'll upload it to mentors.d.n later tonight or tomorrow if anyone wants to take a second look at it. - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tDv7sut7hEFU6Tx5jQS1iXONd6yKQzcnnbEkeTNgg=n...@mail.gmail.com
Bug#609849: nevernote: changing back from ITP to RFP
retitle 609849 ITP: nixnote -- An open source clone designed to interact with Evernote. owner 609849 ! thanks I still intend on packaging Nixnote/Nevernote, but there are a number of dependencies (mostly java ones) that need to be packaged first. - Vincent On Wed, Jul 27, 2011 at 9:02 AM, Lucas Nussbaum lu...@debian.org wrote: retitle 609849 RFP: nevernote -- An open source clone designed to interact with Evernote. noowner 609849 thanks Hi, This is an automatic email to change the status of nevernote back from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 6 months. If you are still interested in adopting nevernote, please send a mail to cont...@bugs.debian.org with: retitle 609849 ITP: nevernote -- An open source clone designed to interact with Evernote. owner 609849 ! thanks However, it is not recommended to keep ITP for a long time without acting on the package, as it might cause other prospective maintainers to refrain from packaging that software. It is also a good idea to document your progress on this ITP from time to time, by mailing 609...@bugs.debian.org. Thank you for your interest in Debian, -- Lucas, for the QA team debian...@lists.debian.org -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBVOPPUENF8ZTstnLOAtiUBb6G=8o-ukhtockz-e...@mail.gmail.com
Bug#634003: ITA: conky -- highly configurable system monitor
On Sat, Jul 16, 2011 at 5:16 PM, Aron Xu happyaron...@gmail.com wrote: You've sent the RFA already, :-) But I'm sorry that you have to wait for another few days, I'm not at home and very busy in the upcoming week. I'll try to work on it earlier, though. -- Regards, Aron Xu No worries; another DD has recently offered to sponsor my Conky packaging as well, so I might not have to trouble you. :) Regards, - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbpkz1ct4hxgobrnxynyiwn3c8arkbcgdfpmbsffmq...@mail.gmail.com
Bug#634241: ITP: disper -- display switcher for attaching/detaching displays easily
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: disper Version : 0.3.0 Upstream Author : Willem van Engen dev-dis...@willem.engen.nl * URL : http://willem.engen.nl/projects/disper/ * License : GPL3 Programming Lang: Python Description : display switcher for attaching/detaching displays easily No more headaches just before your presentation. Disper lets you add and remove display devices at the press of a button. It detects what display devices are attached at the moment, and configures the display output automatically. You can specify whether to clone the output on all displays, or to extend the desktop. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718052158.22069.91522.reportbug@vincent-laptop
Bug#632655: ITA: conky -- highly configurable system monitor
This sounds like a perfect solution! Thank you very much for your intention to implement it. I had thought about something similar, but I didn't dare to suggest it, since it increases the burden on the maintainer's side. I was afraid that such a proposal would have never been accepted! ;-) Well, from my point of view, it's not any more burdensome or complicated than several other possible solutions previously mentionned. Besides, after the first upload, maintaining Conky should be relatively simple. As I said, I am really happy about your plan. I am looking forward to seeing it implemented! Bye, and thanks again. I plan on uploading my packaging to collab-maint sometime tomorrow and have a source package uploaded to mentors.d.n within the next few days. Debian users have been waiting for the latest upstream release of Conky for over half a year, so I don't intend to keep them waiting much longer. :) - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbz1rvyj7xyc0f8ruoxskakc8a4+4lif_guad5idjq...@mail.gmail.com
Bug#632655: ITA: conky -- highly configurable system monitor
On Thu, Jul 14, 2011 at 7:06 AM, Aron Xu happyaron...@gmail.com wrote: Hello Cheng, If you need a sponsor when it's ready, drop me a line please. I'd like to help upload conky. -- Regards, Aron Xu Thank you, I'd really appreciate having a sponsor for my packaging. Once I've uploaded conky to mentors.d.n, I'll let you know. - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tD+uSDCJeimK-A8x6F8T=j1rmawea3crhuocmyiefj...@mail.gmail.com
Bug#634003: ITP: conky-all -- highly configurable system monitor (all features enabled)
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: conky-all Version : 1.8.1 Upstream Author : Brenden Matthews, Philip Kovacs, et. al. * URL : http://conky.sf.net/ * License : GPL3, BSD Programming Lang: C, Lua Description : highly configurable system monitor (all features enabled) As part of my plans to adopt Conky, I've decided to split it into 2 source packages, conky and conky-all. Refer to #579102 for more info. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715203532.13968.35216.reportbug@vincent-laptop
Bug#634003: ITA: conky -- highly configurable system monitor
Conky 1.8.1 is now ready to be uploaded to Debian; I've tested my packages on my own laptop and Conky seems to be working just fine. They're also, of course, pbuilder clean and lintian clean (i.e. no errors/warnings). I've uploaded my packages to mentors.d.n, but haven't sent out a RFS yet (Aron, let me know if you'd like me to do so). conky and conky-all should be uploaded to the archive at the same time. collab-maint: $ svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/conky conky $ svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/conky-all conky-all mentors.d.n: (conky) The upload would fix these bugs: 579102, 604921, 609745, 612904, 628519, 628527, 632655 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/conky - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/conky/conky_1.8.1-1.dsc (conky-all) The upload would fix these bugs: 634003 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/contrib/c/conky-all - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/contrib/c/conky-all/conky-all_1.8.1-1.dsc Kind regards, - Vincent Cheng -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tDXi=u05jypoepfmbud_pjezrnpk-nbv1u+tmnjdp9...@mail.gmail.com
Bug#633808: ITP: xul-ext-zotero -- Iceweasel extension to collect, manage and cite bibliographic information
On Wed, Jul 13, 2011 at 2:42 PM, Theodore Lytras thlyt...@gmail.com wrote: Package: wnpp Severity: wishlist Owner: Theodore Lytras thlyt...@gmail.com * Package name : xul-ext-zotero Version : 2.1.8 Upstream Author : Center for History and New Media, George Mason University * URL : http://www.zotero.org/ * License : Affero GPL v3 Description : Iceweasel extension to collect, manage and cite bibliographic information Zotero is one of the best bibliography managers available. It is available as an extension for Iceweasel and as a Standalone version. A plugin for LibreOffice is also available. I have made a debian package for the iceweasel extension version, and I am uploading it to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=xul-ext-zotero ... Hopefully a sponsor can upload it to debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110713214250.3636.31694.reportbug@localhost Hi, Next time, instead of filing a new ITP bug, please consider assigning any old RFP/ITP bugs to yourself (e.g. #504058). See [1] for more info. Kind regards, - Vincent Cheng [1] http://www.debian.org/Bugs/server-control -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAQqFMhy=LyAjtB+y1h=sqhwajhgmy9gyiy3br...@mail.gmail.com
Bug#633808: ITP: xul-ext-zotero -- Iceweasel extension to collect, manage and cite bibliographic information
Looks like I spoke a bit too soon. Sorry about that! - Vincent -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbmniwznqwtmss64iux1o9zk13vucbj_yhtbjde+u2...@mail.gmail.com
Bug#632655: ITA: conky -- highly configurable system monitor
On Wed, Jul 13, 2011 at 12:23 PM, Francesco Poli invernom...@paranoici.org wrote: On Tue, 12 Jul 2011 12:16:30 -0700 Vincent Cheng wrote: retitle 632655 ITA: conky -- highly configurable system monitor owner 632655 vincentc1...@gmail.com thanks Hello Vincent! I am very happy to see that you decided to adopt conky. Even more happy to see how quickly you came to the rescue! Thanks a lot for your willing to help! I really hope that you manage to adopt it soon and that you are willing to move it back to the main archive, by disabling the nvidia support (see bug #579102 for the details). Once again, many thanks for your intention to help out. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE Hi Francesco, As a longtime Conky (and Debian) user, I'm definitely willing to make sure that Conky is properly maintained in Debian. :) I've taken a close look at #579102 and the various ways this issue can be fixed, I'm inclined to go with a different method altogether; have a source package conky that provides conky-cli and conky-std binaries (and the transitional conky package), both compiled without the --enable-nvidia flag (so it can be moved to main), as well as a new source package named conky-all that provides a conky-all binary, with Nvidia support (the status quo; this would go in contrib). The transitional conky package would depend on conky-all | conky-std (currently it only depends on conky-all), so Debian users with contrib enabled would install the former, and those without contrib would install the latter. If you want a comparison, I suppose this is somewhat similar to how p7zip and p7zip-rar are packaged. Why am I seemingly making this more complicated? Well, for one thing, I personally use the binary Nvidia blob, so I would prefer not to have Nvidia support disabled in Conky. However, I understand why it would be preferable to have Conky in main rather than contrib, and I respect users who don't want to have contrib or non-free enabled in their sources.list. I've also taken a look at Raphael Hertzog's blog post about having different dependencies for the same package synced between Debian and Ubuntu, but that would mean that Debian users would no longer have the option of installing a Conky package with Nvidia support enabled (I don't think that Ubuntu users are the only ones who want this feature). With my solution, Debian users can still install Conky without the need for contrib, yet they also have the option to install a Conky compiled with --enable-nvidia, if they want to; Ubuntu users would not notice any difference. I'd gladly welcome any comments or suggestions. Kind regards, - Vincent Cheng -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB-hYxwoFnsTit=3gzwums+x5k+ykckzhurywehp5d...@mail.gmail.com
Bug#633420: ITP: gecrit -- simple, easy-to-use Python IDE
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: gecrit Version : 2.7 Upstream Author : Groza Cristian kristi9...@gmail.com * URL : http://sourceforge.net/projects/gecrit/ * License : GPL Programming Lang: Python Description : simple, easy-to-use Python IDE gEcrit is a Python IDE, with a focus on simplicity and ease of use. Some of its features include: * Editor geared towards Python, supporting indentation, code folding, syntax highlighting/checking, auto-completion, and bad brace checking * Integrated Python shell * Source tree browser * Autosaving * Multiple tabs * Printing * Spell-checking * Word searching/replacement * Pastebin.com integration -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110710071739.8830.55072.reportbug@vincent-laptop
Bug#622982: ITP: naev -- 2D space trading combat game
Hi, Just a quick update on the current status of my Naev packaging... Naev is mostly ready to be uploaded to the Debian archives, except for the fact that the images currently can't all be rebuilt from source. (My DD insists on being able to rebuild all the images in Naev's source tree from scratch.) Problem with that is: 1) the source for many of those images reside in several different Github repositories (more of a pain to package) 2) 2) some of those images require Blender, and upstream only has Blender scripts compatible with 2.4, not the latest version (2.5) of Blender in the archives, so all those scripts have to be rewritten If anybody would like to help with this, I'd gladly appreciate it. My current packaging can be found in the Debian Games svn repository (mentors.d.n is a bit out-of-date): $ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/naev/ Kind regards, - Vincent Cheng -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbgp81a0+hph5pt_bsqx7aujk4n2eo4lbnreya7yeu...@mail.gmail.com
Bug#628219: RFP: 0ad -- 0ad is a realtime RPG currently in alpha stage, but already one of the greatest games for Linux
Hi, 0 A.D. is only offered in Ubuntu via a PPA, not as an official package. Note that there are several things blocking 0 A.D. from being packaged for Debian at the moment; that includes embedded libraries (e.g. spidermonkey), dependencies on libraries whose versions differ in Debian (i.e. 0 A.D. requires enet 1.2.x whereas Debian testing/sid has 1.3), and a few other issues as mentionned previously on the deb-games mailing list (see [1]). I am currently working on packaging 0 A.D. for Debian [2], and I'll upload it once all pending issues are resolved. Note that there's already an ITP bug open for 0 A.D., so this RFP bug report is superfluous. [1] http://lists.debian.org/debian-mentors/2011/04/msg00128.html [2] $ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/0ad/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinQJhR2uHuVFBbd9orP_GXv0=0...@mail.gmail.com
Bug#613788: Bug #613788: ITP: dropbox -- secure backup, sync and sharing util
retitle 613788 RFP: dropbox -- secure backup, sync and sharing util noowner 613788 thanks I no longer have any interest in working on this package (forgot to change the title to RFP earlier though). Sorry! Regards, - Vincent
Bug#622982: ITP: naev-data -- 2D space trading combat game
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: naev-data Version : 0.4.2 Upstream Author : Edgar Simo bobbens bobb...@gmail.com Nikola Whallon 6.satur...@gmail.com Josiah Schwartfeger Deiz Bas Fournier BTAxis bta...@gmail.com * URL : http://code.google.com/p/naev/ * License : code - GPL-3 ; data - public domain, GPLv2, GPLv3, CC-By (and -SA) 3.0 Programming Lang: C, Lua Description : 2D space trading combat game NAEV is a 2D space trading and combat game, in a similar vein to Escape Velocity. NAEV is played from a top-down perspective, featuring fast-paced combat, many ships and outfits, and a large galaxy to explore. The game is highly open-ended, letting players proceed at their own paces. This package contains the data files for Naev. (For reference, #609295 is my ITP for Naev itself.) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110416111615.724.34673.reportbug@vincent-laptop
Bug#594800: Bug#594802: ITP: 0ad-data -- 3D real-time strategy (RTS) game of ancient warfare
On Thu, Mar 31, 2011 at 8:19 PM, Vincent Cheng vincentc1...@gmail.comwrote:
On Thu, Mar 31, 2011 at 7:16 AM, Bertrand Marc beberk...@gmail.comwrote:
2011/3/31 Vincent Cheng vincentc1...@gmail.com
Hi,
Are there any updates on this? I'm interested in seeing 0 A.D. in
Debian's repositories as well; would you like any help in packaging it?
Kind regards,
- Vincent Cheng
Hi Vincent,
I did the initial packaging work a few months ago now [1]. I don't
remember very well. I think I had working packages, but there was some kind
of hack needed to configure properly (as I remember). There was also a
couple of libraries shipped with the archive, some of them were not part of
Debian last year.
You are welcome if you want to take over this ITP or work on the svn. I am
not sure I'll have plenty of time for 0ad this month.
Regards,
Bertrand
[1] http://svn.debian.org/wsvn/pkg-games/packages/trunk/0ad/
http://svn.debian.org/wsvn/pkg-games/packages/trunk/0ad-data/
I'd be glad to help you out with the packaging, although I admit I've had
very little experience with svn. Is there some sort of quick-start guide for
working with Debian's svn repositories?
Aside from that, I seem to be having quite a bit of trouble getting 0 A.D.
to build itself and run, as documented here [1].
- Vincent
[1] http://www.wildfiregames.com/forum/index.php?showtopic=14568
A working patch was provided on Wildfire Games' forums (and attached with
this e-mail); now 0ad can be successfully built and run. I'm going to upload
my packaging to Debian Mentors and see if anybody would like to sponsor this
package.
- Vincent
Index: lib/file/file.cpp
===
--- lib/file/file.cpp (revision 9141)
+++ lib/file/file.cpp (working copy)
@@ -94,8 +94,8 @@
return LibError_from_errno();
const size_t totalTransferred = (size_t)ret;
- if(totalTransferred != size)
- WARN_RETURN(ERR::IO);
+ //if(totalTransferred != size)
+ // WARN_RETURN(ERR::IO);
monitor.NotifyOfSuccess(FI_LOWIO, accessType, totalTransferred);
return INFO::OK;
@@ -110,29 +110,31 @@
req.aio_fildes = fd;
req.aio_offset = alignedOfs;
req.aio_nbytes = alignedSize;
- struct sigevent* sig = 0; // no notification signal
- aiocb* const reqs = req;
- if(lio_listio(LIO_NOWAIT, reqs, 1, sig) != 0)
- return LibError_from_errno();
- return INFO::OK;
+ //struct sigevent* sig = 0; // no notification signal
+ //aiocb* const reqs = req;
+ //if(lio_listio(LIO_NOWAIT, reqs, 1, sig) != 0)
+ // return LibError_from_errno();
+ //return INFO::OK;
+ return IO(fd, accessType, alignedOfs, alignedBuf, alignedSize);
}
LibError WaitUntilComplete(aiocb req, u8* alignedBuf, size_t alignedSize)
{
- // wait for transfer to complete.
- while(aio_error(req) == EINPROGRESS)
- {
- aiocb* const reqs = req;
- aio_suspend(reqs, 1, (timespec*)0); // wait indefinitely
- }
+ wait for transfer to complete.
+ //while(aio_error(req) == EINPROGRESS)
+ //{
+ // aiocb* const reqs = req;
+ // aio_suspend(reqs, 1, (timespec*)0); // wait indefinitely
+ //}
- const ssize_t bytesTransferred = aio_return(req);
- if(bytesTransferred == -1) // transfer failed
- WARN_RETURN(ERR::IO);
+ //const ssize_t bytesTransferred = aio_return(req);
+ //if(bytesTransferred == -1) // transfer failed
+ // WARN_RETURN(ERR::IO);
alignedBuf = (u8*)req.aio_buf; // cast from volatile void*
- alignedSize = bytesTransferred;
+ //alignedSize = bytesTransferred;
+ alignedSize = req.aio_nbytes;
return INFO::OK;
}
Bug#594800: Bug#594802: ITP: 0ad-data -- 3D real-time strategy (RTS) game of ancient warfare
On Thu, Mar 31, 2011 at 7:16 AM, Bertrand Marc beberk...@gmail.com wrote: 2011/3/31 Vincent Cheng vincentc1...@gmail.com Hi, Are there any updates on this? I'm interested in seeing 0 A.D. in Debian's repositories as well; would you like any help in packaging it? Kind regards, - Vincent Cheng Hi Vincent, I did the initial packaging work a few months ago now [1]. I don't remember very well. I think I had working packages, but there was some kind of hack needed to configure properly (as I remember). There was also a couple of libraries shipped with the archive, some of them were not part of Debian last year. You are welcome if you want to take over this ITP or work on the svn. I am not sure I'll have plenty of time for 0ad this month. Regards, Bertrand [1] http://svn.debian.org/wsvn/pkg-games/packages/trunk/0ad/ http://svn.debian.org/wsvn/pkg-games/packages/trunk/0ad-data/ I'd be glad to help you out with the packaging, although I admit I've had very little experience with svn. Is there some sort of quick-start guide for working with Debian's svn repositories? Aside from that, I seem to be having quite a bit of trouble getting 0 A.D. to build itself and run, as documented here [1]. - Vincent [1] http://www.wildfiregames.com/forum/index.php?showtopic=14568
Bug#594800: Bug#594802: ITP: 0ad-data -- 3D real-time strategy (RTS) game of ancient warfare
Hi, Are there any updates on this? I'm interested in seeing 0 A.D. in Debian's repositories as well; would you like any help in packaging it? Kind regards, - Vincent Cheng
Bug#613788: RFS: Dropbox
I've uploaded Dropbox again to Debian mentors; it includes several suggested fixes, and it's now one step closer to possibly being accepted into Debian. (This isn't my final upload though.) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/non-free/d/dropbox - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/non-free/d/dropbox/dropbox_1.0.20-2.dsc Of the 52 libraries that was originally in the source tarball and in my first upload, only a few remain. I've managed to track down the origins of most of the libraries with apt-file, and instead of including those libraries in the source tarball, I've set those packages as build-depends and used dh_link to establish symlinks to Dropbox's directory. Dropbox now depends on the following packages: python2.5, python-dbus, libbz2-1.0, libssl0.9.8, libdbus-1-3, libdbus-glib-1-2, libpng12-0, libpopt0, librsync1, libsqlite3-0, libssl0.9.8, libstdc++6, libwxbase2.8-dbg, python-wxgtk2.8, zlib1g, python-simplejson, python-netifaces (I've chosen python2.5 over python2.6/3.1 because python2.5 includes all the python-related libraries that Dropbox needs, whereas python2.6/3.1 only includes some.) The following libraries/binaries are still present in the source tarball I've uploaded. - _librsync.so: not present in librsync1. apt-file says that it's included in the packages rdiff-backup and duplicity, but I'm unsure if they are the same libraries. - dropbox: the actual dropbox binary - fastpath.so: I have no idea what this library is, or what purpose it serves. - ncrypt/*: ncrypt is not yet packaged for Debian. It seems that this package has already been requested in a RFP bug report for python-ncrypt. (http://bugs.debian.org/528358) - netifaces/netifaces.pyc: this Python bytecode file doesn't seem to be in Debian's python-netifaces package. I've no idea whether or not this is needed, but I've included it at the moment for safe measure. Eventually, only dropbox will be left in the source tarball. I'll have to find some way between now and my next upload(s) to get rid of the remaining libraries. It looks like I may also have to package python-ncrypt; if nobody else is interested in this package, I'll look into it in the next few days and try to package it. Incidentally, does anyone know where I might possibly find the origin of _librsync.so or fastpath.so? To address a few of the questions/comments I've received over the past few days: - I don't know Dropbox's actual distribution license, which is why the license for the dropbox binary in debian/copyright only consists of Copyright 2008-2011 Dropbox, Inc. All rights reserved. I've contacted upstream to try and find out where I can obtain the actual license for the distribution of Dropbox. - While I don't have the text of the distribution license, the previous Dropbox maintainer has given me a copy of an e-mail conversation he had with a Dropbox employee who granted him permission to distribute Dropbox in Debian. See /usr/share/doc/dropbox/dropbox.mbox. Kind regards, ~ Vincent Cheng vincentc1...@gmail.com
Bug#614051: ITP: python-ncrypt -- python wrapper for OpenSSL
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: python-ncrypt Version : 0.6.4 Upstream Author : Tachyon Technologies Pvt. Ltd. * URL : http://tachyon.in/ncrypt/ * License : MIT Programming Lang: Python Description : python wrapper for OpenSSL NCrypt is a python wrapper for OpenSSL built using Pyrex. It supports: * hash algorithms (md5, sha1, sha256, sha512 etc.) * symmetric encryption algorithms (aes256, aes128, 3des, blowfish etc.) * public key crypto with RSA * diffie-hellman key exchange * create/manipulate X.509 certificates * SSL/TLS network protocol -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110219105926.9356.70884.reportbug@vincent-laptop
Bug#613788: ITP: dropbox -- secure backup, sync and sharing util
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: dropbox Version : 1.0.20-1 Upstream Author : Dropbox, Inc. * URL : http://www.dropbox.com * License : Proprietary Section : non-free/net Description : secure backup, sync and sharing util Dropbox is a Web-based file hosting service operated by Dropbox, Inc. which uses cloud computing to enable users to store and share files and folders with others across the Internet using file synchronization. This package only contains the Dropbox daemon; it does not contain the Nautilus plugin for Dropbox. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217083526.29472.58814.reportbug@vincent-laptop
Bug#610506: ITP: ardentryst -- Action/RPG sidescoller, focused on story and character development
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: ardentryst Version : 1.7.1 Upstream Author : Jordan Trudgett jordan_trudg...@hotmail.com * URL : http://jordan.trudgett.com/ * License : game itself: GPL-3 ; game data/music: CC 3.0 Programming Lang: Python Description : Action/RPG sidescoller, focused on story and character development Ardentryst is an action/RPG sidescoller, focused not just on fighting, but on story, and character development. It features two playable characters and a variety of weapons, items, armour, monsters, and beautiful level scenery and graphics. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110119090820.2188.25780.report...@vincent-laptop.vc.shawcable.net
Bug#610506: ITP: Ardentryst
As a follow-up to my ITP, I've uploaded my Ardentryst packaging to mentors.debian.net; I would appreciate any comments or suggestions. - URL: http://mentors.debian.net/debian/pool/main/a/ardentryst - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ardentryst/ardentryst_1.71-1.dsc Thank you in advance! Kind regards, - Vincent Cheng
Bug#555519: ITP: qtjambi
Hi, Do you still intend on packaging qtjambi (your ITP on Debian has been inactive for over a year)? If so, would you like any help? Best regards, - Vincent
Bug#609849: ITP: nevernote -- An open source clone designed to interact with Evernote.
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: nevernote Version : 0.9.6 Upstream Author : Randy Baumgarte ra...@fbn.cx * URL : http://nevernote.sourceforge.net/ * License : GPL-2 Programming Lang: Java Description : An open source clone designed to interact with Evernote. Nevernote is an open source clone of Evernote, written in Java and designed to run on Linux. Evernote is a collection of software and services that allows users to collect, sort, tag and annotate notes and other miscellaneous information. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110113021157.20316.62790.report...@vincent-laptop.vc.shawcable.net
Bug#609291: ITP: mangler -- A Ventrilo compatible client for Linux
Here's a follow-up description then: Mangler is an open source VoIP client capable of connecting to Ventrilo 3.x servers. It is capable of performing almost all standard user functionality found in a Windows Ventrilo client. Ventrilo is a proprietary VoIP communication software, letting users communicate through voice or text. (As a side question, how long are descriptions supposed to be?) - Vincent On Sat, Jan 8, 2011 at 6:12 AM, Ana Guerrero a...@debian.org wrote: On Sat, Jan 8, 2011 at 1:35 AM, Salvo Tomaselli tipos...@tiscali.it wrote: Description : A Ventrilo compatible client for Linux Perhaps a little bit of effort on the description? On Sat, Jan 08, 2011 at 01:44:49AM -0800, Vincent Cheng wrote: Well, I thought it was supposed to be a simple, concise description. I'm putting in more detail in debian/control and in the manual page that'll come along with the package. For the short description yes, it is supposed to be a short and consice one. But you are missing the long description wherre you should explain what ventrilo is. Ana
Bug#609291: ITP: mangler -- A Ventrilo compatible client for Linux
Thanks, I'll contact them and hope for a reply. :) - Vincent On Sun, Jan 9, 2011 at 6:25 AM, Ana Guerrero a...@debian.org wrote: On Sat, Jan 8, 2011 at 6:12 AM, Ana Guerrero a...@debian.org wrote: On Sat, Jan 8, 2011 at 1:35 AM, Salvo Tomaselli tipos...@tiscali.it wrote: Description : A Ventrilo compatible client for Linux Perhaps a little bit of effort on the description? On Sat, Jan 08, 2011 at 01:44:49AM -0800, Vincent Cheng wrote: Well, I thought it was supposed to be a simple, concise description. I'm putting in more detail in debian/control and in the manual page that'll come along with the package. For the short description yes, it is supposed to be a short and consice one. But you are missing the long description wherre you should explain what ventrilo is. On Sat, Jan 08, 2011 at 11:54:10PM -0800, Vincent Cheng wrote: Here's a follow-up description then: Mangler is an open source VoIP client capable of connecting to Ventrilo 3.x servers. It is capable of performing almost all standard user functionality found in a Windows Ventrilo client. Ventrilo is a proprietary VoIP communication software, letting users communicate through voice or text. (As a side question, how long are descriptions supposed to be?) This one is pretty OK. BTW, maybe it will be good idea maintaining this package inside the VoIP team, http://wiki.debian.org/Teams/VoIP/ You can check with them, I do not know if they will be interested. Ana
Bug#609295: ITP: naev -- 2D space trading combat game
I forgot to add the long description to my ITP, so here it is. Sorry! NAEV is a 2D space trading and combat game, in a similar vein to Escape Velocity. NAEV is played from a top-down perspective, featuring fast-paced combat, many ships and outfits, and a large galaxy to explore. The game is highly open-ended, letting players proceed at their own paces. - Vincent On Sat, Jan 8, 2011 at 1:34 AM, Vincent Cheng vincentc1...@gmail.comwrote: Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: naev Version : 0.4.2 Upstream Author : Edgar Simo bobbens bobb...@gmail.com Nikola Whallon 6.satur...@gmail.com Josiah Schwartfeger Deiz Bas Fournier BTAxis bta...@gmail.com * URL : http://code.google.com/p/naev/ * License : code - GPL-3 ; data - public domain, GPLv2, GPLv3, CC-By (and -SA) 3.0 Programming Lang: C, Lua Description : 2D space trading combat game
Bug#609291: ITP: mangler -- A Ventrilo compatible client for Linux
Just for the record, if there are any interested DDs/sponsors who aren't currently subscribed to the debian-mentors mailing list, here is where you can find my uploaded package for Mangler: - URL: http://mentors.debian.net/debian/pool/main/m/mangler - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mangler/mangler_1.2.1-1.dsc Thanks in advance for your interest and your support! - Vincent On Sun, Jan 9, 2011 at 9:59 PM, Vincent Cheng vincentc1...@gmail.comwrote: Thanks, I'll contact them and hope for a reply. :) - Vincent On Sun, Jan 9, 2011 at 6:25 AM, Ana Guerrero a...@debian.org wrote: On Sat, Jan 8, 2011 at 6:12 AM, Ana Guerrero a...@debian.org wrote: On Sat, Jan 8, 2011 at 1:35 AM, Salvo Tomaselli tipos...@tiscali.it wrote: Description : A Ventrilo compatible client for Linux Perhaps a little bit of effort on the description? On Sat, Jan 08, 2011 at 01:44:49AM -0800, Vincent Cheng wrote: Well, I thought it was supposed to be a simple, concise description. I'm putting in more detail in debian/control and in the manual page that'll come along with the package. For the short description yes, it is supposed to be a short and consice one. But you are missing the long description wherre you should explain what ventrilo is. On Sat, Jan 08, 2011 at 11:54:10PM -0800, Vincent Cheng wrote: Here's a follow-up description then: Mangler is an open source VoIP client capable of connecting to Ventrilo 3.x servers. It is capable of performing almost all standard user functionality found in a Windows Ventrilo client. Ventrilo is a proprietary VoIP communication software, letting users communicate through voice or text. (As a side question, how long are descriptions supposed to be?) This one is pretty OK. BTW, maybe it will be good idea maintaining this package inside the VoIP team, http://wiki.debian.org/Teams/VoIP/ You can check with them, I do not know if they will be interested. Ana
Bug#609291: ITP: mangler -- A Ventrilo compatible client for Linux
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: mangler Version : 1.2.1 Upstream Author : Eric Connell, Daniel Sloof * URL : http://www.mangler.org/ * License : GPL-2, GPL-3, LGPL-2.1 Programming Lang: C, C++ Description : A Ventrilo compatible client for Linux -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110108074536.32082.37288.report...@vincent-laptop.vc.shawcable.net
