RFS: mosquitto (new upstream version)
Dear mentors, I have just uploaded an updated version of my mosquitto package and am looking for a sponsor. * Package name: mosquitto Version : 0.15-1 Upstream Author : Roger Light ro...@atchoo.org * URL : http://mosquitto.org/ * License : BSD Section : net It builds those binary packages: libmosquitto0 - MQTT version 3.1 client library libmosquitto0-dev - MQTT version 3.1 client library, development files libmosquittopp0 - MQTT version 3.1 client C++ library libmosquittopp0-dev - MQTT version 3.1 client C++ library, development files mosquitto - MQTT version 3.1 compatible message broker mosquitto-clients - Mosquitto command line MQTT clients python-mosquitto - MQTT version 3.1 client library, python bindings To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mosquitto Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.15-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Roger -- 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/cah7zdyfb_tebb6mtplx64vgzw8vennjhso5bwkw1faqrug6...@mail.gmail.com
Re: Fwd: RFS: gcc-4.5-doc-non-dfsg
I will try to look sometime soon, but can't promise when. Hello Samuel The gcc-doc thing you've done looks great, however it is incomplete. Complete solution consists of gcc-doc-defaults package [contrib], and several gcc-X.Y.doc-non-dfsg [non-free], that all must match each other. There should be gcc-X.Y.doc-non-dfsg for each gcc-X.Y that is in debian main, and only one of those must provide gcc-doc-base package. Upload must be done for all components in sync (perhaps together with filing RM requests for obsolete source packages). Uploading only part of these will leave things in broken state. E.g. several source packages will provide gcc-doc-base binary package, or gcc-doc-defaults will provide packages with broken depends and/or symlinks. In good old days when I had time and motivation to maintain gcc-doc, I've used git repos to managed entire thing. I've just created externally-available mirror for those - please check http://yoush.homelinux.org:8079/git Could you please clone these repos, and reformat your work into this format? IMO this format greatly helps to keep things consistent. Maybe this could be moved to git.debian.org. As for the rest, here are several more comments: *) I don't really understand the workflow of gcc-doc-non-dfgs converted to 3.0 (quilt) format. With old format, there was debian/patches, managed by dpatch, with part of patches managed by hands, and part managed by a perl script. Running the script altered debian/patches/* files, including series file. But isn't this unsafe for 3.0 (quilt) format since it will break metadata in .pc/ directory? Also, if you convert to 3.0 (quilt), why still mentioning dpatch in README.source? *) Looks like your command line for patch convertion script is much shorter that in was in previous times. How did you check which patches to apply and which not? Actually I've looked at updating gcc-doc during new year holidays, and stopped and postponed it exactly at this point. It was unclear what patches to apply, looked like some procedure/policy was needed, and I could not think your such a policy at that time. The idea was to check what patches are applied for each of in-debian architectures, and apply doc changes for all of those. This could likey be automated, e.g. by writing a makefile that will include debian/rules2 from gcc package, and then use vars set by that to print list of applied patches; some tricks with var-setting could do this for all archs. *) [minor but still] it looks a bit unfair that there is only your signature under README.source, while large part of the text was written by me :). 2. In contemplating putting debian/copyright in DEP-5 format, I've realized that I'm not sure of the exact copyright/licensing status of anything in the debian/ directory, except: See debian/copyright from the old packages. Everything non-autogenerated under debian/ was stated to be GPL; I don't object changing that if needed. Nikita signature.asc Description: This is a digitally signed message part.
RFS: rudeconfig
Dear mentors, I am looking for a sponsor for my package rudeconfig. * Package name: rudeconfig Version : 5.0.5-1 Upstream Author : Matthew Flood * URL : http://rudeserver.com/config/index.html * License : GNU GPL Section : libs It builds those binary packages: librudeconfig-dev - C++ config file library for reading and writing .ini files - deve librudeconfig3 - C++ config file library for reading and writing .ini files - runt To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rudeconfig Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rudeconfig/rudeconfig_5.0.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Medhamsh Hacktivist | http://medhamsh.org -- 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/46868.14.99.21.159.1328445118.squir...@mail.medhamsh.org
Bug#658713: RFS: manaplus
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package manaplus. ManaPlus is client for Evol Online MMORPG and advanced client for The Mana World. ManaPlus most used client in both this games. * Package name : manaplus Version : 1.2.2.5-1 Upstream Author : Andrei Karas * URL : http://manaplus.evolonline.org/ * License : GPL 2 Section : games It builds those binary packages: manaplus - Extended client for Evol Online and The Mana World manaplus-data - Extended client for Evol Online and The Mana World (data files) manaplus-dbg - Extended client for Evol Online and The Mana World (debugging sym To access further information about this package, please visit the following URL: http://mentors.debian.net/package/manaplus Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/manaplus/manaplus_1.2.2.5-1.dsc I would be glad if someone uploaded this package for me. Best regards.
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
tag 657393 + confirmed thanks Hi, Stephen M. Webb stephen.w...@bregmasoft.ca writes: I am looking for a sponsor for my package skstream: dget -x http://mentors.debian.net/debian/pool/main/s/skstream /skstream_0.3.8-1.dsc Are the additional includes from the 0001-gcc-4.4.patch still necessary? At least the two .cpp files now already #include cstring so there is no need to add an additional #include string.h. I did not check if the last #include is still needed. Could you add the Multi-Arch fields as suggested by Jakub Wilk in an earlier mail? Regards, Ansgar -- 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/87wr81fhyg@deep-thought.43-1.org
Re: RFS: rudeconfig
On 05.02.2012 16:31, Medhamsh wrote: Dear mentors, I am looking for a sponsor for my package rudeconfig. * Package name: rudeconfig Version : 5.0.5-1 Upstream Author : Matthew Flood * URL : http://rudeserver.com/config/index.html * License : GNU GPL Section : libs It builds those binary packages: librudeconfig-dev - C++ config file library for reading and writing .ini files - deve librudeconfig3 - C++ config file library for reading and writing .ini files - runt Why another .ini file library is needed, while about 1000 others are already available? Thanks, /mjt -- 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/4f2e9935.2070...@msgid.tls.msk.ru
Re: RFS: rudeconfig
Hello, On Sun, February 5, 2012 8:29 pm, Michael Tokarev wrote: Why another .ini file library is needed, while about 1000 others are already available? I have submitted an ITP for rudecgi parser lib for C++ and uploaded the package to mentors(#658347). After that found all the components of http://rudeserver.com to be interesting. So, wanted to package all of them and started with the .ini file lib. If it is unnecessary re-work I would stop working on it and close the bug. I would also request an opinion whether the core libs at http://rudeserver.com are worth packaging. I want to submit ITPs for all of them. Else I would stop doing the same. Sincerely, -- Medhamsh Hacktivist | http://medhamsh.org -- 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/49221.14.99.21.159.1328455795.squir...@mail.medhamsh.org
Re: Re-review request/RFS for current packaging of Red Eclipse
Hello, Given that I have not received any response to my previous request, and questions, I'm re-sending this. On Tue, 2012-01-17 at 14:35 +0100, Martin Erik Werner wrote: On Tue, 2012-01-17 at 09:47 +0800, Paul Wise wrote: On Mon, Jan 9, 2012 at 6:37 AM, Martin Erik Werner wrote: Hello again, upstream has now released Red Eclipse 1.2 and hence this is partly a RFS, partly a re-review request. ... [1] Is this motivation good enough for not using stand-alone Enet? Hmm, I don't have a good answer for that. [a] I'm hesitant, but I think I'll go with embedded Enet for now, given the indications from upstream. (...) [4] List of duplicates have been forwarded, but it's mostly a wontfix since linking isn't as easy on windows. What about removing the dupes and only referring to the remaining files? The given explanation was[0]: Some files are made available for modding purposes, the rest are impossible to symlink on all platforms. Distribution packagers are free to symlink files in individual packages, but this cannot be done on a project-wide scale. [b] The modding aspect is a reasonable argument for keeping the alternate files separate (they could be different, but aren't currently), I could symlink it all for Debian, and the gain would be about 1.3M, do you think I should? I have updated the packaging a bit since the re-review/RFS request, a few typos, syntax, and style fixes. For each of the git repositories[1] $ git log --since=debian/1.2_RFS $ git diff debian/1.2_RFS should list the changes, I have tagged the state of the repos as of this email with debian/1.2_RFS2. Do you think these packages might be almost good to go? Would you be willing to sponsor them at that point? [c] [0] http://sourceforge.net/apps/trac/redeclipse/ticket/89 [1] (Once Alioth is up:) http://anonscm.debian.org/gitweb/?p=pkg-games/cube2font.git http://anonscm.debian.org/gitweb/?p=pkg-games/redeclipse.git http://anonscm.debian.org/gitweb/?p=pkg-games/redeclipse-data.git Also re-uploaded to mentors: http://mentors.debian.net/package/cube2font http://mentors.debian.net/debian/pool/main/c/cube2font/cube2font_1.2-1.dsc http://mentors.debian.net/package/redeclipse http://mentors.debian.net/debian/pool/contrib/r/redeclipse/redeclipse_1.2-1.dsc http://mentors.debian.net/package/redeclipse-data http://mentors.debian.net/debian/pool/non-free/r/redeclipse-data/redeclipse-data_1.2-1.dsc I'd be grateful if someone could have a look at my questions, and if you think the state of the packaging is good, please upload it. Index: [a] Embedded Enet [b] Symlink dupes in Debian packaging? [c] Packaging links Thanks :) -- Martin Erik Werner martinerikwer...@gmail.com signature.asc Description: This is a digitally signed message part
Bug#657393: RFS: skstream/0.3.6-1 [ITA] -- IOStream C++ socket Library
On 02/05/2012 09:55 AM, Ansgar Burchardt wrote: Stephen M. Webb stephen.w...@bregmasoft.ca writes: I am looking for a sponsor for my package skstream: dget -x http://mentors.debian.net/debian/pool/main/s/skstream /skstream_0.3.8-1.dsc Are the additional includes from the 0001-gcc-4.4.patch still necessary? At least the two .cpp files now already #include cstring so there is no need to add an additional #include string.h. I did not check if the last #include is still needed. Could you add the Multi-Arch fields as suggested by Jakub Wilk in an earlier mail? The patch was no longer required. All patches have now been removed. I added the Multi-Arch fields as suggested. I have uploaded a new source package to mentors.debian.net (same URL as above). -- Stephen M. Webb stephen.w...@bregmasoft.ca -- 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/4f2eac6c.6060...@bregmasoft.ca
RFS: jabber-querybot
Dear mentors, I am looking for a sponsor for my package jabber-querybot. * Package name: jabber-querybot Version : 0.1.0-1 Upstream Author : Marco Balmer ma...@balmer.name * URL : http://github.com/micressor/jabber-querybot * License : GPL-3+ Section : net It builds those binary packages: jabber-querybot - Modular xmpp/jabber bot To access further information about this package, please visit the following URL: http://mentors.debian.net/package/jabber-querybot Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/j/jabber-querybot/jabber-querybot_0.1.0-1.dsc jabber-querybot (0.1.0-1) unstable; urgency=low * New 0.1.0 upstream files * d/dirs: Remove usr/share/jabber-querybot/lib * d/jabber-querybot.install: Removed files which are installed with Makefile.PL * d/preinst: Exec only during upgrade case * d/watch: Update watch file according to new tags I would be glad if someone uploaded this package for me. Kind regards, Marco Balmer signature.asc Description: GnuPG Signature
Re: RFS: rudeconfig
On Sun, 2012-02-05 at 20:59 +0530, Medhamsh wrote: I have submitted an ITP for rudecgi parser lib for C++ and uploaded the package to mentors(#658347). After that found all the components of http://rudeserver.com to be interesting. Are you actually using these components in an application? If you're packaging them just for fun, that's probably not the best use of your time or Debian's archive space, buildds, etc. -- Richard signature.asc Description: This is a digitally signed message part
RFS: burp -- A cross platform network backup and restore program.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package burp. * Package name: burp Version : 1.3.0 Upstream Author : Graham Keeling keel...@spamcop.net * URL : http://burp.grke.net/ * License : AGPLv3 Section : utils It builds those binary packages: burp - backup and restore program To access further information about this package, please visit the following URL: http://mentors.debian.net/package/burp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/burp/burp_1.3.0.dsc I would be glad if someone uploaded this package for me. Changes since the last upload: burp (1.3.0) unstable; urgency=low * Initial release (Closes: #658152) -- Bastiaan Franciscus van den Dikkenberg b...@dikkenberg.net Sun, 05 Feb 2012 21:18:26 +0100 Kind regards, Bas van den Dikkenberg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAk8vElQACgkQInDFGMlxAyPSNACdGKJ7QVBNgZuBKZ6gxRq17rA7 A4oAmwXgcAg2R+Fr2bmBb2V/c6P51n5W =kI5c -END PGP SIGNATURE-
Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library
On 01/30/2012 10:12 PM, Stephen M. Webb wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package atlas-cpp: dget -x http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc I have modified this package to fix missing or added inline symbols on additional non-x86 architectures. I have uploaded a new source package to the same URL. -- 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/4f2f190b.4090...@bregmasoft.ca
Re: RFS: libconfig (requires transition)
Hi Jose, On 03/02/12 00:50, Jose Luis Tallón wrote: My apologies if you did send an e-mail and I didn't read it. My inbox is severely overloaded as of lately... Isn't it good style to notify the maintainer and/or coordinate with them before an NMU ? Apologies. I posted on the -devel thread that I had prepared a package and uploaded to mentors back in December [1] because you said you gave up trying to upload the package [2]. On 31/01/12 00:08, Jonathan McCrohan wrote: Julien Cristaujcris...@debian.org wrote: Please don't change the -dev package name. Yup! All of the packages except one have versioned Build-depends on libconfig8-dev. Surely this needs to be replaced with libconfig-dev or at least libconfig9-dev? No it doesn't? You can rename the -dev package to libconfig-dev if you want, but certainly don't *need* to, and if you do it, then it would be way better from our point of view to keep building libconfig8-dev as a transitional package until the reverse deps are updated, and to do that separately from the SONAME bump. Yes, please. Being bitten a couple times already after not checking buildability of r-deps... it is the library maintainer's responsibility, after all. If its ok, I'll leave the package as is. Sigh. I can change it if it makes it easier for you so. Your paragraph above made it sound as if it didn't matter which way it was done. To clarify, what is the process for this transition? Will the package be uploaded to experimental to allow me to report bug reports and patches against dependant packages? I'm not sure I understand what you're asking. This is my first upload which requires a transition, and I am unsure of what happens next. Please read the library maintainer's guide first (or re-read if needed). It does avoid many a headache... It seems common for packages to be uploaded to experimental for a time prior to the actual transistion to allow other maintainers update their packages accordingly. I was wondering will this be the case with this transition? Well, unfortunately for the world (some would say ;) ), not too many packages depend on libconfig; Nor are they very complex. Therefore, a full transition via experimental and involving the RM is not needed, AFAIK. Just notifying the depending maintainers should suffice (it would be different during freeze, of course) I have already spoken to Julien and I will upload a new package with the -dev packages fixed to experimental. Just drop me a line if I can be of any help. Will do. Thanks, Jon 1: http://lists.debian.org/debian-devel/2011/12/msg7.html 2: http://lists.debian.org/debian-devel/2011/11/msg00416.html -- 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/4f2f25ac.4050...@gmail.com
Re: RFS: burp -- A cross platform network backup and restore program.
W dniu 06.02.2012 00:36, Bas van den Dikkenberg pisze: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package burp. * Package name: burp Version : 1.3.0 Upstream Author : Graham Keeling keel...@spamcop.net * URL : http://burp.grke.net/ * License : AGPLv3 Section : utils It builds those binary packages: burp - backup and restore program To access further information about this package, please visit the following URL: http://mentors.debian.net/package/burp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/b/burp/burp_1.3.0.dsc I would be glad if someone uploaded this package for me. Why is it build as native package? regards fEnIo
