Re: RFS: 0ad
On Thu, Apr 7, 2011 at 12:59 AM, Paul Wise p...@debian.org wrote: On Thu, Apr 7, 2011 at 10:58 AM, Vincent Cheng vincentc1...@gmail.com wrote: - package libenet1.2, and replace 0ad's build dependency on libenet-dev with this new package I'd prefer to have only one version of enet in Debian, but I understand the reasoning here (protocol incompatibility). - package libmozjs185, and remove the spidermonkey code that's currently in the source tarball (this could be deferred until alpha 5 is released, since according to Philip, 0 A.D. hasn't been ported to work with it yet; for now, I guess we'll have to leave the spidermonkey code embedded in the source tarball) Why can't you use the versions of SpiderMonkey already in the archive (1.9.1.18, 2.0)? Similar to why 0 A.D. needs libenet 1.2; Philip explained earlier that 0 A.D. needs a specific version of Spidermonkey (1.8.5) in order to maintain compatibility, since it uses advanced Spidermonkey features and users with different versions of Spidermonkey may run into issues in multiplayer games (as an - determine what, if anything, needs to be removed from the source tarball (the only thing I've removed so far is /libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE) I'd suggest also removing any embedded code copies that aren't used by the Debian package. As for the fonts, since they aren't used during the build or at runtime, would it really be necessary to package them separately (is there any point in having an unused package in Debian's repositories)? Removing them from the source tarball would be a much faster alternative, unless upstream decides to set up a build system to convert/render those fonts at build time. I covered this in my earlier mail, was my guess about how they are used incorrect? Just wanted some clarification; if upstream chooses not to implement a build system where fonts are converted into glyphs/bitmaps during the build, and instead stick with pre-rendered glyphs in the source package, it would be ok to simply strip out the fonts, and not have to package them separately as you suggested in an earlier mail? -- bye, pabs http://wiki.debian.org/PaulWise
Re: RFS: 0ad
On Thu, Apr 7, 2011 at 1:53 AM, Ansgar Burchardt ans...@debian.org wrote: Hi, Vincent Cheng vincentc1...@gmail.com writes: - package libenet1.2, and replace 0ad's build dependency on libenet-dev with this new package We just got rid of enet 1.2 in testing a few days ago and I prefer to have just a single version per release to care about (instead of doubling the number of possible versions from five to ten). For Ubuntu users, upstream could include the newer enet in their PPA. The packages containing the library itself are co-installable, only the -dev packages for enet 1.2 and 1.3 are not. I don't know how to best handle other distributions, but doesn't upstream have to bundle enet anyway for Windows and Mac OS X users? I agree that it would be preferable if we only had to deal with a single enet version, although that depends on whether upstream is willing to port 0 A.D. to enet 1.3. Fortunately, it looks like Philip is willing to consider this option. :) - package libmozjs185, and remove the spidermonkey code that's currently in the source tarball (this could be deferred until alpha 5 is released, since according to Philip, 0 A.D. hasn't been ported to work with it yet; for now, I guess we'll have to leave the spidermonkey code embedded in the source tarball) I suggest to ask the maintainers' of libmozjs-dev how they think about this. I've just sent a message to the Debian Mozilla crew; hopefully we'll get another favourable response. - Vincent
Re: RFS: 0ad
On Thu, Apr 7, 2011 at 8:56 AM, Philip Taylor exc...@gmail.com wrote: On Thu, Apr 7, 2011 at 9:53 AM, Ansgar Burchardt ans...@debian.org wrote: For Ubuntu users, upstream could include the newer enet in their PPA. The packages containing the library itself are co-installable, only the -dev packages for enet 1.2 and 1.3 are not. Hmm, I'm not particularly familiar with how the PPAs work, but if adding enet there requires zero extra effort from users installing the game then I think that'd be okay. Uploading to a Launchpad PPA works practically the same way as uploading a package to Debian would, and it's a lot faster too (nobody needs to review your packaging, for one thing). Once it's up and running, users would simply have to add the PPA to their sources.list, and proceed to install 0 A.D. like any other package. $ sudo add-apt-repository ppa:name-of-ppa $ sudo apt-get update $ sudo apt-get install 0ad Granted, the whole process would be one step shorter if 0ad and all its dependencies are put in Ubuntu's own repositories (so users wouldn't have to add the PPA), but otherwise isn't any more complicated for the user. All that has to be done is to ensure that 0 A.D. and the dependencies that aren't already in Ubuntu's repositories are all uploaded to the PPA, and that these packages take preference over the same packages in Ubuntu's repositories. I don't know how to best handle other distributions, but doesn't upstream have to bundle enet anyway for Windows and Mac OS X users? On Windows we bundle precompiled binaries (.dll and .lib), so that can be upgraded easily and is independent of the Linux / OS X approach. On OS X we don't bundle - we typically use MacPorts which currently provides ENet 1.2 (http://libenet.darwinports.com/) but I think we could give them an upgraded portfile and it'd be immediately available to all users. For all Fedora/Mandriva/OpenSUSE versions I think we could upgrade the library at https://build.opensuse.org/package/show?package=libenetproject=games so it'd work for users who install the game from that service. Arch and Gentoo already have packages for 1.3 and don't have users on old distro versions. I think all other distros that have packages for the game are too minor to worry over - they can sort themselves out as necessary. So, I suppose this could work - just need to set up ENet 1.3 packages for MacPorts and the OpenSUSE Build Service and the Ubuntu PPA, and recompile on Windows, and update the game code. (Not an entirely trivial amount of work, unfortunately :-( ) If you need help with the PPA, let me know and I'll be glad to help (I'm completely unfamiliar with MacPorts or the OpenSUSE Build service though). However, if it turns out to be more trouble than it's worth porting 0 A.D. to enet 1.3, please let us know and we'll try to think of some other solution. - Vincent
/usr/include/linux/videodev.h
Hi all, Does anyone knows where /usr/include/linux/videodev.h has gone ? It has disappear from the latest linux-libc-dev package in sid. Thanks -- Mathieu -- 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/banlktike9ivaxhfg_y7kz8qezdlcohm...@mail.gmail.com
Re: /usr/include/linux/videodev.h
On 2011-04-08 16:18 +0200, Mathieu Malaterre wrote: Does anyone knows where /usr/include/linux/videodev.h has gone ? It has disappear from the latest linux-libc-dev package in sid. It has been removed in Linux 2.6.38 (commit 88ae7624a6fe890e5a8ca57b25420f66e1389f8b in Linus' tree). Sven -- 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/874o68g6cd@turtle.gmx.de
Gratis por TIEMPO LIMITADO
4/8/2011 13:27:21 Todo propietario de un sitio web sabe que conseguir visitantes para el mismo es una tarea dura, y difícil, pero importantísima. El estar bien ubicado en los buscadores es una parte fundamental de la promoción de cualquier sitio web. Debido a que pensamos que el tema puede ser de su interés es que le enviamos a debian-mentors@lists.debian.org este ofrecimiento por tiempo limitado Hoy en día hay tantas opciones para promover un sitio web en internet, que para quien es novato en el tema, pueden crearse confusiones y desconciertos. Muchos se preguntan qué opciones elegir, un alta en buscadores, un intercambio de links, alquilar banners, un resultado patrocinado, las variantes son muchas cada una con su ventaja y su desventaja. Por esa razón, y para asesorar a nuestros clientes hemos creado un curso gratuito de 12 lecciones que le enseña al propietario de un sitio web las mejores opciones para promover su sitio mediante los buscadores de internet. Este curso se diseñó originalmente en forma exclusiva para nuestros clientes, pero en esta ocasión, y por tiempo limitado, le damos a usted la posibilidad de tomarlo, es totalmente gratuito. Este curso consta de 12 lecciones, que le serán enviadas por e-mail, una al día. Cada lección trata en un lenguaje ameno y simple, un tema en particular. Este curso NO le enseñará a dar de alta en buscadores, sino que SI le enseñará sobre las diversas opciones actualmente disponibles en el mercado de promoción mediante internet, y le explicará cómo lograr que su sitio web sea amigable a los ojos de los buscadores Si usted está interesado en aprovechar al máximo las opciones que le dan los diferentes métodos de promoción en internet, en especial el alta en buscadores, sus variantes, y sus complementos, no puede dejar pasar esta oportunidad. Cupo limitado a los 100 primeros suscriptos. Para suscribirse al curso envíe un e-mail en blanco a la casilla de correo curso.espec...@rocketmail.com MUY IMPORTANTE PARA QUE LA SUSCRIPCIÓN AL CURSO SEA EXITOSA DEBE COLOCAR EN EL ASUNTO DEL E-MAIL QUE ENVÍA LA PALABRA SUSCRIBIR. Esto es muy importante, ya que si no coloca la palabra SUSCRIBIR en el asunto o subjet del e-mail que envía no recibirá el curso. Si conoce a alguien que esté interesado en este tema, por favor reenvíele este e-mail. Gracias TC -- 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/20110408132721.4d62ea783d1c7...@telecentro.com.ar
Re: RFS: 0ad
On Thu, Apr 7, 2011 at 5:35 PM, Adam Borowski kilob...@angband.pl wrote: On Thu, Apr 07, 2011 at 04:33:47PM +0100, Philip Taylor wrote: On Wed, Apr 6, 2011 at 1:24 AM, Paul Wise p...@debian.org wrote: Preferably you would render text at run-time, since that enables i18n. For finding font files use fontconfig (preferred) and or a build-time parameter for finding them. My main concern is that that wouldn't provide sufficient consistency - different versions of Freetype, or the same version with different configuration (bytecode interpreter, autohinter, etc), might render the same font quite differently and break the look of the game. Why won't you force the settings then? If you are afraid the user's configuration might be ill-fitting, specify them by hand. The important ones that I'm aware of are compile-time settings (TT_CONFIG_OPTION_BYTECODE_INTERPRETER/TT_CONFIG_OPTION_UNPATENTED_HINTING) so we can't override them. It seems the relevant patents only expired about a year ago, and some distros respected the patents before then - I have no idea how many users are still running systems in the unpatented mode, but in the absence of data I assume it's non-zero, and I'd rather not make changes that add complexity and could make the game worse for some users unless there's sufficient benefit. (I expect this may change in the future - once we eventually add i18n support and non-Latin-alphabet languages there will be some benefit to loading fonts dynamically (and it'd be simpler to load all fonts that way), and I could probably collect data on how many of our users have poor-quality Freetypes if there is no existing data indicating it's a negligible number, but those are probably unlikely to happen within the next few months.) -- Philip Taylor exc...@gmail.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/BANLkTi=Z63gPz6t9jDF9m8QCvZp97it2=a...@mail.gmail.com
Re: RFS: quakespasm (2nd try)
Hi Jon, On 07/04/11 22:55, Jon Dowland wrote: Sorry I missed your first RFP. I have now added basic quake support to game-data-packager and made an upload to experimental. I will hopefully give your package a look real soon and get it uploaded! Thanks for looking at this. I guess we would want to add Recommends: quake-data to control for this package before it is uploaded? I see some of the details wrt. package names are still being gone over in your other thread, so we should probably wait until that's all decided, then I can add the right thing to debian/control.* Cheers, David * I'm not sure if Recommends is correct, just basing that on ioquake3 package. -- 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/innh91$sck$1...@dough.gmane.org
Re: RFS: nautilus-image-manipulator
Hi Julien, Thanks for your answer, which I just read (I am not subscribed to the mentors mailing list) I will update the package according to your comments. Question: do I need to continue replying to the list also, or should we continue this discussion off-list? Tthanks, +Emilien -- 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/banlktik649u5-eijfcvsbzfta9qkke0...@mail.gmail.com
Re: RFS: 0ad
On Fri, Apr 8, 2011 at 6:32 PM, Vincent Cheng vincentc1...@gmail.com wrote: Similar to why 0 A.D. needs libenet 1.2; Philip explained earlier that 0 A.D. needs a specific version of Spidermonkey (1.8.5) in order to maintain compatibility, since it uses advanced Spidermonkey features and users with different versions of Spidermonkey may run into issues in multiplayer games (as an as an ? Just wanted some clarification; if upstream chooses not to implement a build system where fonts are converted into glyphs/bitmaps during the build, and instead stick with pre-rendered glyphs in the source package, it would be ok to simply strip out the fonts, and not have to package them separately as you suggested in an earlier mail? No, since the fonts are the source code for those images and we have DFSG #2. -- 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/BANLkTikuYnSMas1OTONL5Sia2qo1k_4_=g...@mail.gmail.com
Re: RFS: python-crypto (adopting package, fixes FTBFS)
* Sebastian Ramacher s.ramac...@gmx.at, 2011-03-18, 12:32:
http://mentors.debian.net/debian/pool/main/p/python-crypto/python-crypto_2.3-1.dsc
I won't sponsor your package (sorry, I feel deep antipathy towards
dh_python2), but here's my quick review:
* Please consider joining Debian Python Modules Team[0] and maintaining
the package with us.
* Build-dependency on python-setuptools and python-support(!?) was
added, but it's not documented in the changelog.
* You can drop Breaks: ${python:Breaks}, dh_python2 don't fill in this
variable anymore.
* The upstream provides a test suite. Could you please run it at build
time (ideally, with all supported Python versions)?
* My build log contains a series of warnings like:
| In /build/python-crypto-1B0XXA/python-crypto-2.3/lib/Crypto/Random/
| __init__.py:
| Import failed (but source code parsing was successful).
| Error: ImportError: cannot import name SHA256 (line 29)
Maybe you need to set PYTHONPATH while running epydoc?
* Moving python-dbg from Depends to Recommends didn't help, as the final
dependency look like this:
python-crypto (= 2.3-1), libc6 (= 2.3.6-6~), libgmp10, python2.6-dbg | python2.5-dbg,
python-dbg (= 2.5), python-dbg ( 2.7)
I suppose that dh_python2 helpfully generated the dependency for you...
* Why python-crypto-doc is Priority: extra?
[0] http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
--
Jakub Wilk
--
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/20110408224102.ga2...@jwilk.net
Re: RFS: nautilus-image-manipulator
Hi Emilien, Le samedi 09 avril 2011 à 00:05:35 (+0200 CEST), Emilien Klein a écrit : Hi Julien, Thanks for your answer, which I just read (I am not subscribed to the mentors mailing list) Then please, state it in your messages so that I (we) can CC you. I will update the package according to your comments. Question: do I need to continue replying to the list also, or should we continue this discussion off-list? Please keep this discussion on debian-mentors. Others may also have interesting comments. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- 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/20110409051009.ga28...@kirya.net
