Re: RFS: gpick
Hi, On Tue, Sep 07, 2010 at 12:11:30AM +0200, Pietro Battiston wrote: I can't say I have made a deep review - just compiled, tried the app and looked at some files. But I must say the app itself is very practical for any web (and not only web) designer. I would anyway not be able be sponsor since I'm not a DD, but I encourage DDs to not be fooled by the word simple in the motivation above, neither by the intrinsec simplicity that the color picker expression may suggest. This is in my opinion a well written and useful tool, worth a place in Debian. First of all, thanks for your words are truly motivating. The good news is that gpick is pending[0] and very soon will be on Debian :) also I want to thanks to ctaylor. My 2 cents. @Elías: maybe the language and graphic libraries adopted don't deserve a place in the description. Instead, if I was in you I would ensure that the expression color theme appears in it, since that's a fundamental feature of the software. Moreover, there is a redundant space in the second line. Finally, I think the following applies to the package: http://wiki.debian.org/Projects/DebSrc3.0#Doesa3.0.28quilt.29sourcepackageneedtobuild-dependonquilt.3F Thanks to take your time to review gpick. I wanted keep the description like its web and make it sound more familiar. About your others points, I will take them into account. [0]http://ftp-master.debian.org/new/gpick_0.2.2-1.html Regards, -- Elías Alejandro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907061558.ga2...@debianero
Re: RFS: gpick
Il giorno mar, 07/09/2010 alle 01.15 -0500, Elías Alejandro ha scritto: Hi, On Tue, Sep 07, 2010 at 12:11:30AM +0200, Pietro Battiston wrote: I can't say I have made a deep review - just compiled, tried the app and looked at some files. But I must say the app itself is very practical for any web (and not only web) designer. I would anyway not be able be sponsor since I'm not a DD, but I encourage DDs to not be fooled by the word simple in the motivation above, neither by the intrinsec simplicity that the color picker expression may suggest. This is in my opinion a well written and useful tool, worth a place in Debian. First of all, thanks for your words are truly motivating. The good news is that gpick is pending[0] and very soon will be on Debian :) also I want to thanks to ctaylor. Oh... OK, great! Debian fulfills my needs before I find the time to express them. Pietro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1283845302.3391.89.ca...@voubian.casa
Uncertain solutions in packaging buildbot 0.8.1
Dear mentors, Some time ago I mentioned about some solutions in buildbot package I'd like to discuss since I'm not sure if they are completely right. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/buildbot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/buildbot/buildbot_0.8.1-1.dsc My changelog contains the following information: * New upstream version. Closes: #587313. - Fix homepage in debian/control Closes: #587314. - Fix CSS stylesheet is not set for index.html. Closes: #576284. * Switch to dpkg-source 3.0 (quilt) format * New manual pages for buildbot and buildslave binaries. * Split package into two according to new project structure. * Configuration is now stored in apache-like manner for better management. * Switch to /bin/sh interpreter in init-scripts Here are the things I'm not sure: 1. Changelog. The new upstream version fixes all bugs available in Debian BTS. Should I mention all of these bugs like I did or should I just set a list of bugs closed by new upstream without any details? 2. Naming. The upstream separated client and server code and now server binaries and the python package itself are still called `buildbot', and the client binaries and python package are called `buildslave'. However I used `buildbot-master' and `buildbot-slave' for naming packages and system users. The previous version of the package had one system user called `buildbot' however upstream documentation does not recommend such configuration. I could also use one user for both packages as before but I'm not sure how should postrm script work to purge the package (i.e. what to do with buildbot instances inside buildbot home directory). Should I use debconf and ask user during package installation? 3. Init scripts. Prevoius package used bash arrays defined in /etc/default/buildbot to list managed buildbot instances. I used apache-like configuration for both buildbot-master in /etc/buildbot/masters-(available|enabled) and buildbot-slave in /etc/buildbot/slaves-(available|enabled) with almost the same configuration options as were in previous package. However the init-scripts themselves grew dramatically. I also admit that such configuration still needs the buildbot configuration files in /etc/buildbot to be valid shell scripts since they are sourced by init-scripts which is definitely a bad idea. For now I don't know how to solve this problem properly. Also there is no strict mechanism to detect buildbot startup failure and some failure cases are not detected automatically. 4. Unified configuration. I tried to make some unified configuration for all system managed buildbot instances, e.g. use common places to store pids (/var/run/buildbot-*) and logs (/var/log/buildbot-*). I didn't like the way to store all logs from different buildbot instances (which especially have been running by different users) and found the solution in screen package. It uses username as a folder to store files for every user. For example, if we have buildbot master instance called `testbot' which is run by `test' user, we'll have PID-file in /var/run/buildbot-master/test/testbot.pid and log file in /var/log/buildbot-master/test/testbot.log. I should mention that upstream version 0.8.1 had some issues concerning logging (http://buildbot.net/trac/ticket/973) which is fixed in the next release so I added this fix as a patch until the next release. 5. `#! /usr/bin/env python' in scripts generated by setuptools. Curently this is fixed with `sed -i'. I wonder if there is a better solution. I really would like to hear your opinions on this. Thanks in advance. -- with best regards, Andriy Senkovych -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikq7jnzpfvbpsmfsebac+cydokp5grjpzehy...@mail.gmail.com
RFS: python-mechanize (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.2.2-1.1 of my package python-mechanize. It builds these binary packages: python-mechanize - stateful programmatic web browsing The package appears to be lintian clean. The upload would fix these bugs: 465206, 595928 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/python-mechanize - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/python-mechanize/python-mechanize_0.2.2-1.1.dsc I would be glad if someone uploaded this package for me. Kind regards Mikhail Lukyanchenk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=zanwecm0hgjgzmrg4xlpp+okhls6r5h=fu...@mail.gmail.com
RFS: owfs
Dear mentors, I am looking for a sponsor for my package owfs. * Package name: owfs Version : 2.8p2-1 Upstream Author : Paul Alfille palfi...@earthlink.net * URL : http://owfs.org/ * License : GPL-2 Section : misc It builds these binary packages: libow-dev - Dallas 1-wire support: development files libow-php5 - Dallas 1-wire support: PHP5 bindings libow2.8 - Dallas 1-wire support: shared libraries libow2.8-perl - Dallas 1-wire support: Perl5 bindings libow2.8-tcl - Dallas 1-wire support: Tcl bindings libownet-dev - owserver protocol library -- development files libownet-perl - Perl module for accessing 1-wire networks libownet-php - Dallas 1-wire support: PHP OWNet library libownet2.8 - owserver protocol library -- shared library owfs - Dallas 1-wire support owfs-common - common files used by any of the OWFS programs owfs-dbg - Debugging symbols for the OWFS packages owfs-doc - Dallas 1-wire support: Documentation for owfs owfs-fuse - 1-Wire filesystem owftpd - FTP daemon providing access to 1-Wire networks owhttpd- HTTP daemon providing access to 1-Wire networks owserver - Backend server for 1-wire control owserver-utils - Dallas 1-wire support: owserver utilities python-ow - Dallas 1-wire support: Python bindings python-ownet - Python module for accessing 1-wire networks The package appears to be lintian clean. The upload would fix these bugs: 325159 My motivation for maintaining this package is: provide a very useful interface for communicating with the Dallas 1-wire networks. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/owfs - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/owfs/owfs_2.8p2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ilya Pravdivtsev -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8640ae.5000...@gmail.com
RFS: gnustep-gui (RC bugfix)
Dear mentors, I am looking for a sponsor for the new version 0.18.0-5 of my package gnustep-gui. It builds these binary packages: gnustep-gui-common - GNUstep GUI Library - common files gnustep-gui-doc - Documentation for the GNUstep GUI Library gnustep-gui-runtime - GNUstep GUI Library - runtime files libgnustep-gui-dev - GNUstep GUI header files and static libraries libgnustep-gui0.18 - GNUstep GUI Library libgnustep-gui0.18-dbg - GNUstep GUI Library - debugging symbols The upload would fix these bugs: 595757 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnustep-gui - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/g/gnustep-gui/gnustep-gui_0.18.0-5.dsc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq2hk0qi.gnus_not_unix!%ya...@gnu.org
RFS: viewpdf.app (NMU, RC bugfix)
Dear mentors, I am looking for a sponsor for the new version 1:0.2dfsg1-3.1 of the package viewpdf.app. It builds these binary packages: viewpdf.app - Portable Document Format (PDF) viewer for GNUstep The upload would fix these bugs: 595763 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/viewpdf.app - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/v/viewpdf.app/viewpdf.app_0.2dfsg1-3.1.dsc -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwxlk00a.gnus_not_unix!%ya...@gnu.org
Re: Help with uswsusp
Hi, Thanks for your replies. On 07/09/10 01:50, Eriberto wrote: In the body. 2010/9/6 Rodolfo kix Garciak...@kix.es: - maintainer-upload-has-incorrect-version-number 0.9-0.0 (normal) Solved by lustin. Now I have other problem :-( - unused-debconf-template (minor) You can't keep unchanged debconf templates (original templates) into the package. I can't inspect your package because you don't uploaded uswsusp_0.9-0.0.debian.tar.gz file. uploaded :-) - hyphen-used-as-minus-sign (whislist) Yeap. The manpage can't have minus signals. You must to use \-. Please, see the patch in my package jp2a (# apt-get source jp2a). Yes, I understand this, but this package has the file s2ram.8 and debian/s2ram.xml. The first file (s2ram.8) is generated from the xml file. I don't know how to solve the problem, because if I change - to \- in the xml file, then the manual (man s2ram) page shows \- :-( Regards, Eriberto - Brazil On the other hand, the package runs fine. Best Regards, Rodolfo. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c867b8c.2040...@kix.es
Re: RFS: veusz
Apologies: I didn't say that this upload would fix bug 447524. -- Jeremy Sanders jer...@jeremysanders.net http://www.jeremysanders.net/Cambridge, UK Public Key Server PGP Key ID: E1AAE053 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lfd.2.00.1009071950580.25...@xpc1.ast.cam.ac.uk
RFS: veusz
Dear mentors, I am looking for a sponsor for my package veusz. * Package name: veusz Version : 1.9-2 Upstream Author : Jeremy Sanders * URL : http://home.gna.org/veusz/ * License : GPLv2+ (small PSF part) Section : science It builds these binary packages: veusz - A scientific plotting and graphing application The package appears to be lintian clean. My motivation for maintaining this package is: I'm the upstream author. Other people have tried to get a package in Debian and in Ubuntu but failed to do that. The program is quite mature now and is included in a few other distributions (e.g. Fedora). It seems a shame for Debian users to have to download a binary tar.gz to get my program to work! If you saw the earlier version on mentors.debian.net (-1), this version now uses debhelper and python-support (rather than CDBS and python-central). Veusz is mostly written in Python with a small amount of C and C++. It also provides a python module interface, so it is a application/module crossover (the application is just a small script accessing the module). Lintian does suggest in wishlist that the non architecture specific part of the package (93%) should be separated. I've done a lot of web searching but haven't worked out how to get debhelper 7 and python-support to allow me to do this. The package isn't very large however (1MB deb). Lintian also says that an extra license file is included. It is not. I've filed a lintian bug about that (#595941). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/veusz - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/veusz/veusz_1.9-2.dsc I would be glad if someone uploaded this package for me. Kind regards Jeremy Sanders -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lfd.2.00.1009071933520.25...@xpc1.ast.cam.ac.uk
Re: Help with uswsusp
On 07/09/10 01:40, Kan-Ru Chen wrote: Hi! On Tue, Sep 7, 2010 at 6:05 AM, Rodolfo kix Garciak...@kix.es wrote: * URL : http://suspend.sourceforge.net/ but the new version is in git.kernel.org (http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-utils.git;a=tree) It isn't released yet, right? The suspend-utils (common name) is created and maintained by Rafael and Pavel. They are working now in the kernel, in the power management. The software is in a very stable versión, but the problem is the database. A new machine, new entry in the database. For example, some bugs of uswsusp are because this machines are not in the database. Now I am trying to maintain the database (from 8 months ago), and the project was moved from sourceforge to git.kernel.org, but there is not a new version in the webpage. The database is important because it has the flags for the suspend to ram, an example: Acer *, Aspire 5100 *, , , VBE_SAVE|PCI_SAVE|S3_MODE, From the 0.8 version to 0.9 has some important bugs solved in the code and many new machines were added. About the question, I am not sure if Rafael will release a new version 0.9 to sourceforge, but the uswsusp debian package is very old, has many bugs and should be upgraded. I am not sure the future of this package if it is not upgraded. * License : GNU GPL * Section : admin The package can be found on my server, probably I will move it to mentors.debian.net: - URL: http://www.kix.es/src/suspend-utils/debian/ The package is not complete, missing uswsusp_0.9-0.0.debian.tar.gz I uploaded it, sorry. Cheers, Kanru Thanks a lot. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c868f5b.1000...@kix.es
postinst script
Hi I have a command line in postinst script of a package that works ok outside a package install context . one line is causing an error : cat /proc/file | grep XYfile without the grep - no error with the grep the postinstall terminates with error(below) . dpkg: error processing package(--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: Any idea why or limitations of postinst script thanks Zvi Dubitzky Email:d...@il.ibm.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/of1f666b9b.d9604c01-onc2257797.006d54a6-c2257797.006e4...@il.ibm.com
Re: postinst script
On Tue, Sep 7, 2010 at 9:04 PM, Zvi Dubitzky d...@il.ibm.com wrote: Hi I have a command line in postinst script of a package that works ok outside a package install context . one line is causing an error : cat /proc/file | grep XY file without the grep - no error with the grep the postinstall terminates with error(below) . dpkg: error processing package(--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: Any idea why or limitations of postinst script That's because grep does not match XY in /proc/file and returns with an error code - 1 (0 would be a success). At the same time, you probably have set -e somewhere at the beginning of your script - and this is causing a script to stop (quit) as soon as any command fails (returns with an error code). cheers, Tomek -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikxu7tr+s4cgjcdatoabzrubs6akzqtyuei-...@mail.gmail.com
Re: postinst script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 7 Sep 2010 23:04:56 +0300 Zvi Dubitzky d...@il.ibm.com wrote: Hi I have a command line in postinst script of a package that works ok outside a package install context . one line is causing an error : cat /proc/file | grep XYfile grep returns 1 if it doesn't something that matches your expression. add an echo if you don't care about your result or you want to change something along the way cat /proc/file | grep XY file if [ $? -eq 0 ]; then # Success condition... echo Found XY! cat file else # Exit condition... echo Didn't find XY! echo Check XX and YY that there is in fact what you need. fi By default (if my bash-fu is correct), $? (if we're talking bash) will result in the last return call.. So if i have a script which calls grep test /proc/file last and doesn't actually call exit or return, $? will contain the return value of grep as though you had said return $? So, either check what you're doing with grep (which may be your biggest problem!) or eat the value of $? by calling an echo (or just return!) - -- Morgan Gangwere Key ID A8B6F243, available from MIT. BOFH excuse #301: appears to be a Slow/Narrow SCSI-0 Interface problem -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJMhp2FAAoJEEURiCSotvJDDYsP/225jXM8dx14JZb2rqsDJ3Tt SiBa+kI11yMf/wjkDYEKgdXmhtgeS+4Z1toCZy6dqXD1wmZZb5xHZpH6sm+kdiXl e3yqaLT9NM8odQx2oqxKQJbDaFUXLIWFXC6QZPwH8hNwSbgSjL7f+OdL8YmTfnuz atHWIXzKfy+iFc+VDavyDvXrPjAVd/1gIKfEK2Se8cW896T+ttJCD+NwFrYsAMv0 A+4VyC5w/deXL2SKJRh/Cu1DW5x5LPnKeOgUNOI7nOazZmkzueq8JXA5G0NvBEkx Um0trcY5atnbFm9rc0qm5zgLCSeT1OZyJqhH1psc891xE/EPWSpsoVb00kHtNSM9 AlPkOblxmfJSD3Nu4QK1uS1sgEB9GOQfE5dFnMhYt3QBMz9qdiodbfMlrtu7yj57 KRSi/OBLO0i/UcdL4t7qhFL1d6tlkIrmi3iHbdrp0lRKFD9cLDhJVGhNhk+PJbC0 6nf/pNrho+qkHY4FOF6giDW102A6kOAIz+OOwz/wQJTe+V1yVvmSKQOgKIr5cnBc O6lcxDUHQOI54PMCjCsvUTknWcVeJsnOxwQpqMjdCIjWqrVTLCZ9kOmKiylkx+p/ lNH/ggF3zfPpOp8NU90De1IEw7iw1ttTjexgNLnw/2Jid9fm7KDclW4S3Kz44mtZ qlzTZwE0XTj74shP0wMX =+RkU -END PGP SIGNATURE-
Re: RFS: sslh (updated package)
On 09/01/2010 03:52 PM, Guillaume Delacour wrote: I am looking for a sponsor for the new version 1.7a-1 of my package sslh. I just uploaded this. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c86f752.2050...@icecavern.net
Re: RFS: python-mechanize (updated package)
On Tue, Sep 7, 2010 at 8:53 PM, Mikhail Lukyanchenko m...@uptimebox.ru wrote: I am looking for a sponsor for the new version 0.2.2-1.1 of my package python-mechanize. At this stage of the release cycle, unimportant changes should be targetted at experimental not unstable. A new upstream version is not appropriate for an NMU. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimpxbkn15uqg_0p-z7gvcxawknhq1qtpmbln...@mail.gmail.com
Re: Include 0AD, a new fancy 3D RTS
On Tue, Sep 7, 2010 at 10:27 PM, Philip Taylor exc...@gmail.com wrote: Note that the game requires an obsolete version of Premake with lots of custom patches - a standard version will fail to work. (Ideally the game would upgrade to a recent Premake (and send any still-necessary patches upstream), or switch to something like CMake, but that's likely to take a fair amount of effort and introduce lots of new portability bugs that have been squeezed out of the current system, so we haven't been rushing to do that.) Ouch. That will need to be fixed before it can enter Debian. Also we require FCollada with custom patches, to fix some crashes when loading certain files, and to fix some memory corruption bugs. So I wouldn't suggest replacing it with a random version of FCollada from somewhere else, or using our version of it for any other project. The problem here is there's no upstream for FCollada any more (the developers decided to focus on their commercial work instead), and other projects seem to all use their own forks of it. Maybe what we should do is set up a new fork as a standalone project (i.e. create a new unofficial upstream), give it a proper build system, import the patches from our game and from elsewhere and keep it actively maintained, and then distros can package that version and other applications can hopefully share it. (http://trac.wildfiregames.com/ticket/562 is related to this.) Ouch. Your plan there sounds like a good idea. For SpiderMonkey, we don't need custom patches, but older versions will have thread-safety bugs (the API guarantees were changed) and newer versions have incompatible APIs. The SpiderMonkey developers aren't interested in doing stable releases, and it's a core piece of our game engine so we rely on lots of its minor details for correctness and performance. Also there's a good chance of multiplayer out-of-sync errors when players have different versions of SpiderMonkey. Since the game is tightly tied to a specific version, I don't know what options would work better than the current approach of bundling the required version. I guess we'll have to wait for the situation to change before adding the game to Debian. On a related note: We're probably going to add the NVIDIA Texture Tools (http://code.google.com/p/nvidia-texture-tools/) as a dependency in the next week or so. But I don't think we need any special versions or patches, so a normal package should work and hopefully it won't be a problem. (Since most (all?) distros don't have packages for it yet, I'd still like to bundle it by default, so people won't have to waste time downloading and installing it themselves; but I'll add a flag to use the non-bundled library, for people who have a packaged version.) Please don't bundle it in your source tarball. Instead, make a separate tarball for dependencies and get folks to download that. In addition, it sounds like you want to make 0AD only work on nVidia cards with non-free drivers since this texture tools thing seems to rely on CUDA? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimcy=czqj8_ekbcxdbc9xv5wkg_qy49vkayt...@mail.gmail.com
Re: Include 0AD, a new fancy 3D RTS
PS: Since you seem to be upstream, please take a look at our upstream guide: http://wiki.debian.org/UpstreamGuide -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktintbh0nht=7uymrvduwsvkstgb0sdq5y_zqi...@mail.gmail.com
Re: RFS: veusz
On Wed, Sep 8, 2010 at 2:45 AM, Jeremy Sanders jer...@jeremysanders.net wrote: My motivation for maintaining this package is: I'm the upstream author. Other people have tried to get a package in Debian and in Ubuntu but failed to do that. The program is quite mature now and is included in a few other distributions (e.g. Fedora). It seems a shame for Debian users to have to download a binary tar.gz to get my program to work! Since you are upstream, please check out our upstream guide: http://wiki.debian.org/UpstreamGuide -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=37as+yatw48umq8z37wktphya9fflx6hd6...@mail.gmail.com
