Re: RFS: webcpp (adoption, bugfix and standards/dh7)
Hello Jonathan, On Sat, Nov 29, 2008 at 03:15, Jonathan Wiltshire [EMAIL PROTECTED] wrote: there is a config.log file left in diff.gz, please remove it in the next upload (probably before the 'rm' in config), but apart from that the package looks fine so I uploaded it. Fixed this in 0.8.4-7, if you have a moment perhaps you could take a look? (there's no hurry) Thanks for the quick fix, but I don't think it deserves another upload: leave it there for the next bunch of changes. Regards, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Čihař a écrit : Hi Most of things were already answered in Matthews reply, I only react on missing things. Dne Thu, 27 Nov 2008 22:14:56 +0100 Laurent Guignard [EMAIL PROTECTED] napsal(a): - debian/rules: - rm -f can not fail, so you can strip some useless test commands - test ! -f Makefile || ./debian/rules config.status - dependencies in makefile should ensure this Yes sure for rm -f and its possible fail. I thought it was a cleaner method to test the file exists before running a command on, but may be i am wrong ? The test is okay, but why do you invoke debian/rules? If you need config.status to be up to date, just make it a dependency of rule where you need it. The main difference i can see, is that someone that download the source package could manualy run a ./configure with his own options and generate his own Makefile that could be used after to generate a specific package (may be with a special path...). If i put a dependency on the install rule, this possibility disappear and all dpkg-buildpackage will build the same package. May be this freedom to the system administrator that build the package hasn't to be there ? Have a good week-end Best regards - -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJMTeFjcKpXFc/7oYRAubAAJ44zDH22cHtReD2NhzyT8Lr/oZqUACbBQ+S wp+vg5Z3ye0/YYEb74F1BNc= =X+G5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Matthew Palmer a écrit : On Thu, Nov 27, 2008 at 10:14:56PM +0100, Laurent Guignard wrote: Michal ??iha?? a écrit : Hi [...] Quick look at the package: - any reason why it is Architecture: i386? In reason of the libraries dependency. libnet1 package is for i386 architecture and dhcp_probe use it with previous update of this library in order to provide specific functions needed by dhcp_probe. #apt-cache show libnet1 Package: libnet1 [...] *Architecture: i386* That shows the binary package information on your system. If you'd run that on an arm system, dhcp-probe would now be an arm-only package. Examine the source package info, or just look at http://packages.debian.org/sid/libnet1 for the list of architectures that a package is built for. But at any rate, your argument is bollocks -- packages should have the architectures listed that *it* supports, regardless of it's dependencies. What if libnet1 *was* an i386-only package at the moment, but then in a month's time someone makes it truly arch-neutral and it builds for all arches? Much easier for everyone if your package doesn't need any changes to support more arches. OK, that is a new information for me. I thought, before your comment, that aptitude show xxx show all architectures available for a package and it is not ! Thanks for information. I have another question about architecture : How is it possible to check if a package could be built on architecture without the appropriate hardware ? I can say that dhcp-probe could be build on i386 and any compatible architectures and with the upstream notes, i can say that dhcp-probe could be built on sparc but how to test on other architectures ? May be i am wrong, but i think it is impossible to build a package on architectures that are not supported by needed libraries ? It's impossible to build, yes, but that situation will be adequately dealt with by the autobuilders. - why you manually create some directories and files? dh_install and dh_installdirs should do the job better and nicer. Anyway most of these dirs do not have to be created (examples) or look simply wrong to me (/etc/default/dhcp-probe) [...] The /etc/default/dhcp-probe directory is used to store all configuration files needed (one for each interface on which dhcp-probe is used). I thought that it was the best solution instead of spreading all configuration files directly in /etc. dh_installinit will automatically put a default file in place if asked nicely. See the appropriate man page for more details. - Matt Yes, dh_installinit will automatically put *a* default file in place. As you noticed, it place *A* default file. That i would like to do, is to place at least one file and i doesn't know how many because it depends of the number of network interfaces the host on which the package is installed has ! May be dh_installinit has the possibility to do this with --name option but in the man page it isn't specified if the dh_installinit script support multiple --name option. Moreover, all default option (for each interface) if generated on fly during postinst step, is it possible to run dh_installinit in postinst script ? So at my level in Debian knowledge, i use ucf, as Michal saids, to do the job. I need help to check if my ucf first time usage is correct or not. Best regards. - -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJMTecjcKpXFc/7oYRArjeAJ0ZYmn194qPJCkYnAVhdGyJxgRskQCfU+3X qL1xPJzZx6fpTDoKl09Z/0M= =y2f/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: inkscape-textext
Dear mentors, I am looking for a sponsor for my package inkscape-textext. * Package name: inkscape-textext Version : 0.4.4-1 * Upstream Author : Pauli Virtanen [EMAIL PROTECTED] * URL : http://www.elisanet.fi/ptvirtan/software/textext/ * License : BSD Section : graphics It builds these binary packages: inkscape-textext - Inkscape extension for editable LaTeX text or formula The package appears to be lintian clean. The upload would fix these bugs: 500777 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/inkscape-textext - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_0.4.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Salvatore Bonaccorso signature.asc Description: Digital signature
Re: RFS: inkscape-textext
Salvatore Bonaccorso scrisse: Dear mentors, I am looking for a sponsor for my package inkscape-textext. inkscape-textext - Inkscape extension for editable LaTeX text or formula I'm not really in favor of this ITP, as it mainly seems as a wring reaction to the latex extension not working properly. All main inkscape extensions are maintained within the upstream repo as the extension interface is used to change a lot between each release, and so they could broke often. You should talk to textext upstream to better integrate with inkscape upstream. What is surely missing is a better separation of inkscape core and all other extensions, which was already proposed for 0.47 but not yet realized. I definitely would not welcome a one-package-per-extension policy, that is the field where your package is currently going. Thus I'm suggesting you to drop this ITP, work with Wolfram (which currently seems a bit busy) to fix the other two related bugs, suggest your upstream to get in touch with Inkscape developers to integrate the extension avoiding duplicate code and maybe start discussing a better extensions packaging (which would be really appreciate, IMHO). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpuspe4dvfmG.pgp Description: PGP signature
Re: RFS: dhcp-probe, another try to request with a lot of update
On Sat, 29 Nov 2008 13:37:25 +0100 Laurent Guignard [EMAIL PROTECTED] wrote: I thought it was a cleaner method to test the file exists before running a command on, but may be i am wrong ? The test is okay, but why do you invoke debian/rules? If you need config.status to be up to date, just make it a dependency of rule where you need it. The main difference i can see, is that someone that download the source package could manualy run a ./configure with his own options and generate his own Makefile that could be used after to generate a specific package (may be with a special path...). If i put a dependency on the install rule, this possibility disappear and all dpkg-buildpackage will build the same package. That is the intention - new options should be set by changing debian/rules. If people want to build the upstream source with different options, they can use the .orig.tar.gz. May be this freedom to the system administrator that build the package hasn't to be there ? Don't call debian/rules - you probably don't want config.status at all, whether it is up to date or not. config.status is normally removed either by 'make distclean' or 'fakeroot debian/rules clean'. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpPqlk4DCfcZ.pgp Description: PGP signature
Re: RFS: dhcp-probe, another try to request with a lot of update
On Sat, 29 Nov 2008 13:37:48 +0100 Laurent Guignard [EMAIL PROTECTED] wrote: I have another question about architecture : How is it possible to check if a package could be built on architecture without the appropriate hardware ? As long as all the dependencies exist on all the available architectures and as long as the package itself does not insist on a particular architecture in the ./configure, then the package will need to build on all architectures. If it does not, that is a FTBFS bug. The only time to exclude particular architectures for a particular package is if the package has no possible role on such architectures or relies on dependencies that have no possible role. If a package relies on particular hardware that is only available for certain architectures, that would be a reason to only specify those architectures. Without such limitations, all packages must build on all architectures supported by Debian - failure to fix those bugs is likely to result in the removal of the package from Debian. What you can do is make sure that the package build is as portable as possible by using things like 'make distcheck' and ensuring that it always completes. You can try and build the package on whatever hardware you can access - a good range would be i386, amd64 and powerpc. Most of that hardware is relatively easy to obtain or request access. I can say that dhcp-probe could be build on i386 and any compatible architectures and with the upstream notes, i can say that dhcp-probe could be built on sparc but how to test on other architectures ? It has to build on sparc, you are required to ensure that it does by fixing any FTBFS bugs that appear and those will provide a lot of the information you need to fix the bug. In that case, your sponsor can help you test the package on the actual hardware. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp8fcwUtHK2l.pgp Description: PGP signature
Re: RFS: inkscape-textext
Dear Luca On Sat, Nov 29, 2008 at 03:18:43PM +0100, Luca Bruno wrote: Salvatore Bonaccorso scrisse: Dear mentors, I am looking for a sponsor for my package inkscape-textext. inkscape-textext - Inkscape extension for editable LaTeX text or formula I'm not really in favor of this ITP, as it mainly seems as a wring reaction to the latex extension not working properly. Many thanks for your reaction on this! Indeed yes, you are right, it was a porbably to fast reaction. I will so the sponsoring request on mentors.debian.net again. First, before I also answer to your other paragraphs: do you think, there is a change that the patch found in launchpad bugtracker (See Bugreport #506285) can go into the inkscape package? This will render back again the LaTeX formula rendering for 0.46 again. It would be really great to have this working again, out of the box. All main inkscape extensions are maintained within the upstream repo as the extension interface is used to change a lot between each release, and so they could broke often. You should talk to textext upstream to better integrate with inkscape upstream. Thanks for the suggestion! I will try to drop an email to the textext upstream autor if this is possible! I definitely would not welcome a one-package-per-extension policy, that is the field where your package is currently going. I have again cancelled now my request on mentors.debian.net about this. Sorry about that. Thus I'm suggesting you to drop this ITP, work with Wolfram (which currently seems a bit busy) to fix the other two related bugs, suggest your upstream to get in touch with Inkscape developers to integrate the extension avoiding duplicate code and maybe start discussing a better extensions packaging (which would be really appreciate, IMHO). Ok I will try to again reach Wolfram via BTS, as found in 506285 there is a patch to have at least in 0.46 the exporting (but without reediting) formula again working, but I haven't get a reply from Wolfram about this. Many thanks again for your work and for your reply. Hope my english is understandable. Kind regards Salvatore signature.asc Description: Digital signature
Re: RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise
[ Please reply to -mentors at least ] On Fri, Nov 28, 2008 at 5:37 PM, S'orlok Reaves [EMAIL PROTECTED] wrote: I have split libwaitzar off from scim-waitzar and built a separate package: http://mentors.debian.net/debian/pool/main/s/scim-waitzar/ http://mentors.debian.net/debian/pool/main/l/libwaitzar/ Cool, see below for a review of libwaitzar (all I have time for right now). ...but I cannot do the same for KaNaung. There are several reasons for this: 1) KaNaung was developed specifically for Windows. Most of the code I borrowed had to be modified up before it would compile under Linux. 2) I used SVN revision 700 of kanaung's source; the upstream developer has since closed the source for later revisions. (I have written permission of the copyright holder to use the newest source of kanaung, but I chose to only include kanaung code which is covered under the GPL.) Oh, that sucks. If you are able to get later but still GPLed revisions from upstream, that might be a good idea. It might be a good idea to produce a kanaung fork with a new name and focusing on keeping it suitable for use in a free software distribution. Then you could package the kanaung fork separately. Is scim-waitzar directly derived from the Windows WaitZar? The user manual seems to indicate that you relicensed parts of it from BSD to GPL, which you usually aren't allowed to do unless you wrote them. Yes, I wrote both scim-waitzar and Windows WaitZar. In order to make the line clearer, I removed all of the Windows WaitZar code from scim-waitzar and put it into the libwaitzar package. The libwaitzar package is licensed under Apache 2.0, but please let me know if the licenses conflict and I will dual-license it. According to the FSF, the Apache 2.0 license is compatible with the GNU GPL 3 but not GPL GNU 2. http://www.gnu.org/licenses/license-list.html#apache2 http://waitzar.googlecode.com/svn/trunk/release_1.5+_beta/Myanmar3.ttf http://waitzar.googlecode.com/svn-history/r219/trunk/release_1.5/Zawgyi-One.ttf If these are DFSG-free and are Unicode fonts, you might want to join the Debian Fonts Task Force and package them too. I'll consider it, but I've had a hard time contacting the developers of Myanmar3 and Zawgyi-One Thanks for the info. At least things have moved on since the days of Burmese using ASCII and a special font. I think something like khmeros.org would be a great way to promote adherance to Unicode and other standards. Please run lintian -i -I on your package I've fixed all lintian errors in both packages. Unfortunately, one warning remains: W: libwaitzar1: package-name-doesnt-match-sonames libwaitzar-1.0-1.0-1 I've checked online, checked other debian packages... You'll want to read libpkg-guide: http://packages.debian.org/libpkg-guide http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html In your case, the SONAME is determined by libwaitzar_1_0_la_LDFLAGS. A review of the packages: The library... There is one more lintian -i -I issue: I: libwaitzar1: no-symbols-control-file usr/lib/libwaitzar-1.0-1.0.so.1.0.0 Please see these links: http://wiki.debian.org/UsingSymbolsFiles http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-shlibdeps http://manpages.debian.net/cgi-bin/man.cgi?query=deb-symbols http://manpages.debian.net/cgi-bin/man.cgi?query=dpkg-gensymbols What is the preferred form of modification for Myanmar.model? Do you modify it directly? Is the transitional package libwaitzar-dev needed? Please note that dev packages for libraries should be named libwaitzar-dev or libwaitzarAPINUMBER-dev rather than libwaitzarSONAME-dev. You should not ship README/etc in transitional packages. Seems to me like you should merge libwaitzar1-dev into libwaitzar-dev. With libraries, usually they are automatically installed and the dev package description is the only one for human consumption. Therefore the dev package should be written for a human and the library package can be minimalistic (say just the last sentence of the current desc). Similarly you probably don't need the upstream changelog in the library package. Generally a static library isn't needed in distributions like Debian, you might want to drop it. It should be shipped in the dev package rather than the library package anyway. The .so symlink should be shipped in the dev package but not the library package. About /usr/share/waitzar, it might be a good idea to version that directory with the SONAME so that libwaitzar1 will be co-installable with libwaitzar2 when the ABI changes. Alternatively, either compile the model and text file into the library itself or maybe split it out into a libwaitzar-data package. Personally I would expect /usr/include/waitzar-1.0/waitzar to be /usr/include/waitzar, since it is that way for most packages. Same for the pkgconfig file. Also, Makefile.in and any other generated files should not be
Re: RFS: gxemul segfault bugfix
On Mon, 2008-11-24 at 21:31 +0200, George Danchev wrote: On Monday 24 November 2008 17:27:16 Jonathan Wiltshire wrote: Change: added patch 05_segfault_params.dpatch and included it in 00list. Closes: LP #301041 Helping Ubuntu folks is also very nice, and to be honest I was not aware of that LP magic. Hi, Just to note that the above doesn't quite match the syntax required to auto-close the bug, it needs a colon after the LP. For those that read perl the expression is $changes =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/ig so the above should be LP: #301041. Thanks for your help, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: librcd
Dear mentors, I am looking for a sponsor for my package librcd. Package name: librcd Version : 0.1.11-2 Upstream Author : Suren A. Chilingaryan [EMAIL PROTECTED] URL : http://rusxmms.sourceforge.net/ License : GPL Section : libs It builds these binary packages: librcd - Russian Charset Detection Library librcd-dev - Russian Charset Detection Library - dev files The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/librcd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/librcd/librcd_0.1.11-2.dsc I would be glad if someone uploaded this package for me. Kind regards Ivan Borzenkov signature.asc Description: This is a digitally signed message part.
RFS: librcc
Dear mentors, I am looking for a sponsor for my package librcc. Package name: librcc Version : 0.2.6-2 Upstream Author : Suren A. Chilingaryan [EMAIL PROTECTED] URL : http://rusxmms.sourceforge.net/ License : GPL Section : libs It builds these binary packages: librcc - Library for autoconvert codepages librcc-dev - librcc dev files The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/librcc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/librcc/librcc_0.2.6-2.dsc I would be glad if someone uploaded this package for me. Kind regards Ivan Borzenkov signature.asc Description: This is a digitally signed message part.
Re: Re: RFS: xinha
Hi, 2008/11/27 Raphael Geissert [EMAIL PROTECTED]: Hi, [...] debian/uupdate-wrapper: | gzip xinha_$version.orig.tar.gz use max compression (a.k.a -9) Done But looks like you didn't re-compress the tarball using -9, please do. it is done now. But doesn't save much space. [...] There are a couple of issues in xinha itself that I will be reporting later (security issues). Do you happen to have an email address of upstream? I couldn't find it anywhere on the website. Nope. But there are some webpages: James Sleeman: http://code.gogo.co.nz/contact/index.html Raimund Meyer: http://xinha.raimundmeyer.de/ (email may be ray AT openplans.org) Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net Yogi Berra - I never said most of the things I said. Mathieu Parent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: inkscape-textext
Salvatore Bonaccorso scrisse: First, before I also answer to your other paragraphs: do you think, there is a change that the patch found in launchpad bugtracker (See Bugreport #506285) can go into the inkscape package? This will render back again the LaTeX formula rendering for 0.46 again. It would be really great to have this working again, out of the box. [...] Ok I will try to again reach Wolfram via BTS, as found in 506285 there is a patch to have at least in 0.46 the exporting (but without reediting) formula again working, but I haven't get a reply from Wolfram about this. I haven't inspected the patch yet, but if not too intrusive the release team could still allow the fix in Lenny (given also the current release delay). I heard that Wolfram was having mail problem, I hope now you can both collaborate for a bugfix revision targeting lenny. TIA for your interest and contribute. Kind regards Salvatore Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpNslC4yK3nV.pgp Description: PGP signature
Re: A little question of a license
I'm no legal genius, but it looks fairly benign. Basically it says, as long as you give us credit for the code, you can do whatever you want with it. - Lawrence Leopold Palomo-Avellaneda wrote: Hi, I would like to ask if a software that contains a file with this: -- Copyright (C) 2005, XX All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names of its contributors may not be used to endorse or promote products derived from this software without specific prior written permission. -- could be in main? (so is dfsg) I think that yes, but I must admit that the legal stuff is something unclear to me. Something as the classical licenses are clear, but this custom makes me crazy. Regards, Leo No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.8.1/1728 - Release Date: 10/16/2008 7:38 AM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500769: RFS: inkscape-textext
Hi altogether! [...snip...] I'm not really in favor of this ITP, as it mainly seems as a wring reaction to the latex extension not working properly. Many thanks for your reaction on this! Indeed yes, you are right, it was a porbably to fast reaction. I will so the sponsoring request on mentors.debian.net again. First, before I also answer to your other paragraphs: do you think, there is a change that the patch found in launchpad bugtracker (See Bugreport #506285) can go into the inkscape package? This will render back again the LaTeX formula rendering for 0.46 again. It would be really great to have this working again, out of the box. Yes, this patch will be part of the next upload of the inkscape package :-) [...snip...] With best wishes, Wolfi signature.asc Description: Digital signature
Re: RFS: librcc
из того что вижу при проверке: 1. на все новые пакеты должны быть написаны ITP, тебе явно lintian ругается на это: * Initial release (Closes: #) is the bug number of your ITP тут вместо #nnn должен быть номер ITP 2. если идет аплоад нового пакета в changes должны быть все записи changelog'а (опция -v debuild/dpkg-buildpackage) 3. copyright оформлен неправильно, блок License: GPL не пропустят просто нужен как минимум GPL'ный дисклаймер это то что я увидел в diff.gz, однако как писал в предыдущем письме - пакет просто не распаковался, потому что неправильно подписан/суммы неверные указаны On 18:10 Sat 29 Nov , ivan wrote: i Dear mentors, i I am looking for a sponsor for my package librcc. i Package name: librcc i Version : 0.2.6-2 i Upstream Author : Suren A. Chilingaryan [EMAIL PROTECTED] i URL : http://rusxmms.sourceforge.net/ i License : GPL i Section : libs i It builds these binary packages: i librcc - Library for autoconvert codepages i librcc-dev - librcc dev files i The package appears to be lintian clean. i The package can be found on mentors.debian.net: i - URL: http://mentors.debian.net/debian/pool/main/l/librcc i - Source repository: deb-src http://mentors.debian.net/debian unstable main i contrib non-free i - dget http://mentors.debian.net/debian/pool/main/l/librcc/librcc_0.2.6-2.dsc i I would be glad if someone uploaded this package for me. i Kind regards i Ivan Borzenkov -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: RFS: gxemul segfault bugfix
On Sat, Nov 29, 2008 at 02:32:22PM +, James Westby wrote: Just to note that the above doesn't quite match the syntax required to auto-close the bug, it needs a colon after the LP. For those that read perl the expression is In the changelog the syntax was correct and the bug has been closed. -- Jonathan Wiltshire signature.asc Description: Digital signature
Re: RFS: librcc
sorry, mistake in To address :) signature.asc Description: Digital signature
RFS: mina (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.7.dfsg-5 of my package mina. It builds these binary packages: libmina-java - Java network application framework libmina-java-doc - Java network application framework - documentation The package appears to be lintian clean. The upload would fix these bugs: 507203 mina: Missing build dependency on gjdoc The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mina - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mina/mina_1.1.7.dfsg-5.dsc I would be glad if someone uploaded this package for me. Cheers, -- Damien Raude-Morvan signature.asc Description: This is a digitally signed message part.
Re: RFS: mina (updated package)
Le samedi 29 novembre 2008 20:58:49 Vincent Fourmond, vous avez écrit : Hello, Hi, I'll take care of it. Thanks ! Damien Raude-Morvan wrote: I am looking for a sponsor for the new version 1.1.7.dfsg-5 of my package mina. It builds these binary packages: libmina-java - Java network application framework libmina-java-doc - Java network application framework - documentation The package appears to be lintian clean. The upload would fix these bugs: 507203 mina: Missing build dependency on gjdoc Everything seems fine for me. One comment though: I believe the examples would serve more their purpose in the -doc package rather than in the library package. I'm waiting for a reply on that to upload. Moving example source code to -doc package seems a rational suggest to me. I've just uploaded a new version including this change to mentors (same debian revision). Regards, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Re: RFS: mina (updated package)
Hello, I'll take care of it. Damien Raude-Morvan wrote: I am looking for a sponsor for the new version 1.1.7.dfsg-5 of my package mina. It builds these binary packages: libmina-java - Java network application framework libmina-java-doc - Java network application framework - documentation The package appears to be lintian clean. The upload would fix these bugs: 507203 mina: Missing build dependency on gjdoc Everything seems fine for me. One comment though: I believe the examples would serve more their purpose in the -doc package rather than in the library package. I'm waiting for a reply on that to upload. Cheers, Vincent -- If you put a large switch in some cave somewhere, with a sign on it saying End-of-the-World switch. PLEASE DO NOT TOUCH, the paint wouldn't even have the time to dry. -- Terry Pratchet, Thief of Time Vincent, not listening to anything for now -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams a écrit : On Sat, 29 Nov 2008 13:37:48 +0100 Laurent Guignard [EMAIL PROTECTED] wrote: I have another question about architecture : How is it possible to check if a package could be built on architecture without the appropriate hardware ? As long as all the dependencies exist on all the available architectures and as long as the package itself does not insist on a particular architecture in the ./configure, then the package will need to build on all architectures. If it does not, that is a FTBFS bug. The only time to exclude particular architectures for a particular package is if the package has no possible role on such architectures or relies on dependencies that have no possible role. If a package relies on particular hardware that is only available for certain architectures, that would be a reason to only specify those architectures. Without such limitations, all packages must build on all architectures supported by Debian - failure to fix those bugs is likely to result in the removal of the package from Debian. What you can do is make sure that the package build is as portable as possible by using things like 'make distcheck' and ensuring that it always completes. You can try and build the package on whatever hardware you can access - a good range would be i386, amd64 and powerpc. Most of that hardware is relatively easy to obtain or request access. I can say that dhcp-probe could be build on i386 and any compatible architectures and with the upstream notes, i can say that dhcp-probe could be built on sparc but how to test on other architectures ? It has to build on sparc, you are required to ensure that it does by fixing any FTBFS bugs that appear and those will provide a lot of the information you need to fix the bug. In that case, your sponsor can help you test the package on the actual hardware. On the upstream README file, Irwin said that : This version runs on Solaris 9 on SPARC, compiled with gcc. So for me, dhcp-probe could be built on this platform. I haven't any possibility to test the package on this type of architecture and i haven't any assigned sponsor too. If anyone want to sponsor me but i am not sure to want to follow all steps of the Debian New Maintainer process. I am not sure to have enough time to assume this task. But i am sure to have enough time to contribute with one or two packages. May be after i seen the amount of time needed i could follow the Debian New Maintainer process... But i always need a sponsor for dhcp-probe package ;) Have a good week-end. Best regards. - -- Laurent Guignard, Registered as user #301590 with the Linux Counter Site : http://www.famille-guignard.org Blog : http://blog.famille-guignard.org Projet : http://sicontact.sourceforge.net GULL de Villefranche sur Saône : http://www.cagull.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJMahdjcKpXFc/7oYRAjpKAJsF32PnQUVhTebywz9Ww9wU9bx5bQCePYnq OqIwgAOMqIaMZ3zoskHqPqk= =O3zG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
[...] On the upstream README file, Irwin said that : This version runs on Solaris 9 on SPARC, compiled with gcc. So for me, dhcp-probe could be built on this platform. I haven't any possibility to test the package on this type of architecture and i haven't any assigned sponsor too. If anyone want to sponsor me but i am not sure to want to follow all steps of the Debian New Maintainer process. I am not sure to have enough time to assume this task. But i am sure to have enough time to contribute with one or two packages. May be after i seen the amount of time needed i could follow the Debian New Maintainer process... But i always need a sponsor for dhcp-probe package ;) You don't get assigned one, but once your package is in shape it will likely be sponsored by someone. So keep improving your package, as you already do, and report back once you have fixed the remaining concerns. Best, Michael pgp4B6i7PnAev.pgp Description: PGP signature
[uploaded] Re: RFS: mina (updated package)
Hello, Damien Raude-Morvan wrote: Moving example source code to -doc package seems a rational suggest to me. I've just uploaded a new version including this change to mentors (same debian revision). On its way ;-) Cheers, Vincent -- The moon was high now, in a sky as black as a cup of coffee that wasn't very black at all. -- Terry Pratchet, Men at arms Vincent, listening to Achilles Last Stand (Led Zeppelin) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
On Sat, Nov 29, 2008 at 01:37:48PM +0100, Laurent Guignard wrote: I have another question about architecture : How is it possible to check if a package could be built on architecture without the appropriate hardware ? I can say that dhcp-probe could be build on i386 and any compatible architectures and with the upstream notes, i can say that dhcp-probe could be built on sparc but how to test on other architectures ? You don't test it yourself. When it's uploaded with Arch: any, it gets built on all architectures. If the build fails, you'll be notified of it (via a bug). Those bugs then get fixed. If it builds, but fails to run properly on an arch, then someone will find that out and lodge a bug too. The /etc/default/dhcp-probe directory is used to store all configuration files needed (one for each interface on which dhcp-probe is used). I thought that it was the best solution instead of spreading all configuration files directly in /etc. dh_installinit will automatically put a default file in place if asked nicely. See the appropriate man page for more details. Yes, dh_installinit will automatically put *a* default file in place. As you noticed, it place *A* default file. That i would like to do, is to place at least one file and i doesn't know how many because it depends of the number of network interfaces the host on which the package is installed has ! Uhm... no. That's not how it's done. /etc/default/file is a shell fragment that configures the operation of /etc/init.d/file. /etc/default is not a place for random config junk because you don't want to mkdir /etc/package. I repeat: DO NOT put your package's general config data in /etc/default. Put all that configuration data in /etc/dhcp-probe. If the init scripts for the package are currently structured such that there is one init script per configured interface, someone needs to learn to use for loops. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
On Sat, 29 Nov 2008 21:38:53 +0100 Laurent Guignard [EMAIL PROTECTED] wrote: It has to build on sparc, you are required to ensure that it does by fixing any FTBFS bugs that appear and those will provide a lot of the information you need to fix the bug. In that case, your sponsor can help you test the package on the actual hardware. On the upstream README file, Irwin said that : This version runs on Solaris 9 on SPARC, compiled with gcc. So for me, dhcp-probe could be built on this platform. I haven't any possibility to test the package on this type of architecture and i haven't any assigned sponsor too. Your eventual sponsor has all the access necessary to build and test the package - you don't need to worry about that, you just fix the bugs that result (with the help of your sponsor). Your task is merely to ensure that the package will build on all architectures supported by Debian with or without any confirmation or statements from upstream. Your package must build on all architectures where the dependencies can be met - you do not have that choice. It must be built and you must fix the bugs that may appear (feeding the results back upstream) with the help of your sponsor. There is no getting out of it - dhcp-probe must build on all architectures where the dependencies can be met. (It is just as unacceptable to create dependencies that would artificially restrict the package to particular architectures. That is a misuse of Policy.) If you do not do this, the package might never be sponsored and may still be rejected by ftp-master. If you want this package in Debian, *you* are responsible for fixing bugs that arise on all architectures supported by Debian, whether or not upstream have any support for those architectures. Debian will provide all the tools and resources necessary for your sponsor to help you with this task but it is still your task and you cannot avoid it. If anyone want to sponsor me but i am not sure to want to follow all steps of the Debian New Maintainer process. In that case, I will not sponsor you. http://people.debian.org/~codehelp/#join I am not sure to have enough time to assume this task. But i am sure to have enough time to contribute with one or two packages. May be after i seen the amount of time needed i could follow the Debian New Maintainer process... But i always need a sponsor for dhcp-probe package ;) Other sponsors have different requirements but my requirements include that maintainers must be intending to join Debian via the New Maintainer process. For me, sponsoring is a means to an end - getting more people into Debian. (I don't care about whether we get more packages out of it, in fact I think Debian has quite enough packages already - hence I look more for RFS relating to existing packages.) -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpW03fFWjaOj.pgp Description: PGP signature
Re: RFS: freespeak
Luca Bruno [EMAIL PROTECTED] (28/11/2008): I would be glad if someone uploaded this package for me. Taken care of after some modifications. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: freespeak
On Sun, Nov 30, 2008 at 01:26:16AM +0100, Cyril Brulebois wrote: Luca Bruno [EMAIL PROTECTED] (28/11/2008): I would be glad if someone uploaded this package for me. Taken care of after some modifications. Thanks very much for uploading my package. -- http://syx.googlecode.com - Smalltalk YX http://lethalman.blogspot.com - Thoughts about computer technologies http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Re: RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise
Thanks for your review; I will address all of your points in turn later. At present, though, there is one in particular I'd like to clarify: Personally I would expect /usr/include/waitzar-1.0/waitzar to be /usr/include/waitzar, since it is that way for most packages. Same for the pkgconfig file. The guide I read on pkgconfig said that doing /usr/include/waitzar-1.0/waitzar allows non-Debian developers to make install two different versions of the library at the same time. I'm a newbie developer, so I have no idea if this is just overkill. Is /usr/include/waitzar sufficient? All the code is in a namespace anyway, so I don't think there'll be any conflicts. I'll trust your opinion on this one, but I thought I'd explain my thought process first. Cheers, --Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: basic256 (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.9.2-3 of my package basic256. It builds these binary packages: basic256 - educational BASIC programming environment for children The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/basic256 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/basic256/basic256_0.9.2-3.dsc I would be glad if someone uploaded this package for me. Kind regards Ryan Kavanagh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
