Bug#691051: Status
What is the status of this package? -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABP4BswDK74KOMvH=DcjB7M9fOVD1114t=b8m79p6v1lmvn...@mail.gmail.com
Bug#693412: RFA: pybtex - BibTeX-compatible bibliography processor
Package: wnpp Severity: normal Since I am not so much into LaTeX related software anymore, I would like to request an adopter for the package pybtex. cf. http://packages.qa.debian.org/p/pybtex.html Greetings, Daniel Stender -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a5f91e.5070...@danielstender.com
Processed: Fix missing descriptions in titles of O: bug reports.
Processing commands for cont...@bugs.debian.org: retitle 693229 O: crashmail -- JAM and *.MSG capable Fidonet tosser Bug #693229 [wnpp] O: crashmail Changed Bug title to 'O: crashmail -- JAM and *.MSG capable Fidonet tosser' from 'O: crashmail' thanks Stopping processing here. Please contact me if you need assistance. -- 693229: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693229 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135305431419462.transcr...@bugs.debian.org
Processed: wnpp inconsistencies
Processing commands for cont...@bugs.debian.org: # package arpwatch: bugs O 686996 and O 693374 are not merged merge 693374 686996 Bug #693374 [wnpp] O: arpwatch -- Ethernet/FDDI station activity monitor Bug #686996 [wnpp] O: arpwatch -- Ethernet/FDDI station activity monitor Merged 686996 693374 # ITP missing for package aften at mentors (wnpp bugs: 681730) retitle 681730 ITP: aften -- ATSC A/52 (AC3 audio) encoder Bug #681730 [wnpp] RFP: aften -- ATSC A/52 (AC3 audio) encoder Changed Bug title to 'ITP: aften -- ATSC A/52 (AC3 audio) encoder' from 'RFP: aften -- ATSC A/52 (AC3 audio) encoder' owner 681730 JoseM glasn...@gmail.com Bug #681730 [wnpp] ITP: aften -- ATSC A/52 (AC3 audio) encoder Owner recorded as JoseM glasn...@gmail.com. thanks Stopping processing here. Please contact me if you need assistance. -- 681730: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681730 686996: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686996 693374: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693374 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135305808313991.transcr...@bugs.debian.org
Bug#690905: freedoom: Prboom Plus should be used instead of Prboom
On Tue, Nov 13, 2012 at 01:00:29PM +0100, Fabian Greffrath wrote: I'd like to move forward with packaging prboom-plus, but I find it unacceptable to maintain two forks of such similarity in Debian... Long term I think I probably agree with you. We should probably not have both in jessie. But, I'd like to give prboom+ a proper evaluation before I'd consider dropping prboom - so I think they should coexist prior to the next release, so prboom+ gets plenty of exposure in Debian. I've just put some initial packaging work at git+ssh://git.debian.org/git/pkg-games/prboom+.git I had hoped we could use the upstream VCS rather than import tarballs, but sadly they have not tagged/branched their most recent releases. At least this way, I've only imported tarballs that have been filtered via fix_upstream.sh (forked from prboom's version) so the VCS content is DFSG-clean too. I've opted for prboom+ as the binary/source package name, rather than prboom-plus. Upstream use different ones in different circumstances, but as long as + is valid in debian package names I don't see why we shouldn't use it. The upstream binary name is prboom-plus, so I've put in a symlink for prboom+ since I don't like it when binary package names don't correspond to the supplied binary name (where possible). I haven't yet done the symlink for the manpage too. Plenty more work to do… -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116103235.GA25250@debian
Bug#673637: Adoption
I intend to adopt this package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/E1TZJPq-0002vs-Ms@shorty.local
Processed: your mail
Processing commands for cont...@bugs.debian.org: retitle 673637 ITA: tcpflow -- TCP flow recorder Bug #673637 [wnpp] O: tcpflow -- TCP flow recorder Changed Bug title to 'ITA: tcpflow -- TCP flow recorder' from 'O: tcpflow -- TCP flow recorder' End of message, stopping processing here. Please contact me if you need assistance. -- 673637: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673637 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135306267512993.transcr...@bugs.debian.org
Bug#690905: freedoom: Prboom Plus should be used instead of Prboom
Am 16.11.2012 11:32, schrieb Jon Dowland: Long term I think I probably agree with you. We should probably not have both in jessie. But, I'd like to give prboom+ a proper evaluation before I'd consider dropping prboom - so I think they should coexist prior to the next release, so prboom+ gets plenty of exposure in Debian. Maybe we should contact prboom upstream and ask if they are going to maintain prboom any further. Are you in contact with them? I've just put some initial packaging work at git+ssh://git.debian.org/git/pkg-games/prboom+.git It still says prboom in some places and I think prboom+ uses sdl-image, so this would be missing as a build depends. But thanks for starting it, anyway! I had hoped we could use the upstream VCS rather than import tarballs, but sadly they have not tagged/branched their most recent releases. At least this way, I've only imported tarballs that have been filtered via fix_upstream.sh (forked from prboom's version) so the VCS content is DFSG-clean too. I am fine with this! I've opted for prboom+ as the binary/source package name, rather than prboom-plus. Upstream use different ones in different circumstances, but as long as + is valid in debian package names I don't see why we shouldn't use it. The upstream binary name is prboom-plus, so I've put in a symlink for prboom+ since I don't like it when binary package names don't correspond to the supplied binary name (where possible). I haven't yet done the symlink for the manpage too. Hm, I think using a '+' in file names somehow feels unclean, but I have no strong objections. We should sure keep symlinks for both notations. Plenty more work to do… Sure, expect me so join in as an Uploader anytime soon. ;) - Fabian -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a61d04.9040...@greffrath.com
Bug#690905: freedoom: Prboom Plus should be used instead of Prboom
On Fri, Nov 16, 2012 at 12:01:24PM +0100, Fabian Greffrath wrote: Am 16.11.2012 11:32, schrieb Jon Dowland: Long term I think I probably agree with you. We should probably not have both in jessie. But, I'd like to give prboom+ a proper evaluation before I'd consider dropping prboom - so I think they should coexist prior to the next release, so prboom+ gets plenty of exposure in Debian. Maybe we should contact prboom upstream and ask if they are going to maintain prboom any further. Are you in contact with them? Why not. I haven't been for a while but I'll happily fire them off an email. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116111749.GC25250@debian
Bug#690157: [Aptitude-devel] Fwd: Bug#690157: ITP: aptitude-robot -- Automate package choice management
Hi, Daniel Hartwig wrote: On 10 October 2012 23:02, Elmar S. Heeb el...@heebs.ch wrote: Framework to use aptitude for automated package management including upgrade, installation, removal, hold, etc. Allows you to automate what you would manually do with aptitude. See also pkgsync, cron-apt, apticron. We used cron-apt before for a long time. It just does upgrades or mail about pending upgrades and as far as I know you can't tell them that they should upgrade some packages and some not. pkgsync is much closer to what we have in mind with aptitude-robot and after looking at the source code, I must admit that the way it uses aptitude is very close to ours. (From the description alone it looked less like what we have in mind.) I note that the configuration is an imperative style: an explicit list of (aptitude-specific) actions to take. I suspect that with a declarative config. (similar to pkgsync) there would be less unexpected side-effects. Actually our first thoughts were even closer to pkgsync than we are now. Clearly this program is simply meant as an automated interface to aptitude, although I think that most use cases would be covered by pkgsync if also supported list of packages to *not* upgrade. As you noticed, the main difference to pkgsync is that aptitude-robot allows to automatically upgrade most packages but to not automatically upgrade some explicitly listed packages. To make that easier with different sets of hosts or single hosts which need indiviual changes we use run-parts to read in the package lists from multiple, ordered files. With this it's possible to distribute the base package list to all hosts while other, more specific package lists will be distributed only to a subset of the hosts. These package lists can override entries in the base package list, especially they can prevent automatic upgrades of a package on individual hosts while they get automatically upgraded on most hosts. The idea behind this is that while we can do fully automatic upgrades on workstations, we want controlled upgrades of core services on servers while automatic upgrading stuff like commandline utilities is fine. There are also cases where we want automatic upgrades of specific server software one most hosts, but not on all. Common examples for this are Apache and Postfix: Postfix is installed on all our servers. Those which need postfix just to send mails themselves have a simple default configuration and postfix on them is not really critical. On the other hand, Postfix also runs on our primary mail server and while its ok to automatically upgrade commandline utilities on that box, we do not want automatic upgrades of Postfix there. Same situation with Apache: While Apache is installed on quite some boxes to provide access to local statistic web pages or simple web interfaces, it also runs on our primary webserver with several hundered VHosts. We do not want automatic Apache upgrades there while they're fine on other infrastructure servers. There are some more differences, partially in the details: * We allow both, holds and keeps to be configured. * We allow both, purges and removes to be configured. * We honour aptitude holds (ok, that would be trivial to implement in pkgsync, i.e. it's probably a bug in pkgsync that it doesn't honour holds. :-) * aptitude-robot by itself allows questions to be presented on the commandline. Only aptitude-robot-session will silence those questions. Any comments on the distinction, and the particular novelties of your approach? aptitude-robot should be as close as possible to the interactive use. So, yes, it's on purpose rather imperative than declarative. Essentially you should be able to record your interactive session and write it down as configuration files for aptitude-robot. Any ideas how it could synchronize with the periodic apt script that performs update, clean, etc.? From our experience there is an inherent problem between multiple tools handling automatic package list updates and package upgrades stepping on each others toes. This is the main reason why we stopped using cron-apt and disabled apt periodic in favour of aptitude-robot. But our discussion about how to reply to this question just gave us the idea that we may be able to run aptitude-robot triggered by apt periodic. We'll investigate this idea. From aptitude-robot-session: # yes forces the default answer to any configuration question nice yes | /usr/sbin/aptitude-robot Have you considered something more explicit, such as: # aptitude -y -o DPkg::Options::=--force-confdef \ -o DPkg::Options::=--force-confold … Good point! Thanks. Though these options currently have problems when a package fails to install or remove. From TODO: * allow package+ and packageM (or m) to be both specified for the same package (currently the last one wins) I guess you would combine these internally to “+M”? Yes and no. See
Bug#690905: freedoom: Prboom Plus should be used instead of Prboom
Am 16.11.2012 12:17, schrieb Jon Dowland: Why not. I haven't been for a while but I'll happily fire them off an email. Thanks for taking care of that! -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a634e8.4010...@greffrath.com
Bug#690157: ITP: aptitude-robot -- Automate package choice management
On 16 November 2012 20:36, Axel Beckert a...@debian.org wrote: We used cron-apt before for a long time. It just does upgrades or mail about pending upgrades and as far as I know you can't tell them that they should upgrade some packages and some not. On a single system, possible, since you basically specify the complete apt command line(s). When trying to use a central config plus local tweaks that is definitely not easy :-) pkgsync is much closer to what we have in mind with aptitude-robot and after looking at the source code, I must admit that the way it uses aptitude is very close to ours. (From the description alone it looked less like what we have in mind.) I had somewhat imagined the setup you later describe, though with your details I can easily see how a declarative syntax would also have to be rather complex to handle that level of local-system overriding and so on. I once had a pipe dream of a declarative syntax that would support default actions and package lists (like pkgsel's “make sure these are installed, and these others are not”) with local overrides, and it ended up looking a lot like apt_preferences :-/ Clearly this program is simply meant as an automated interface to aptitude, although I think that most use cases would be covered by pkgsync if also supported list of packages to *not* upgrade. As you noticed, the main difference to pkgsync is that aptitude-robot allows to automatically upgrade most packages but to not automatically upgrade some explicitly listed packages. To make that easier with different sets of hosts or single hosts which need indiviual changes we use run-parts to read in the package lists from multiple, ordered files. I had assumed that pkgsync supported a similar run-parts type config, allowing local overrides, etc.. But anyway, it can't do what you want unless you can override the default to “upgrade all packages” with “but not package X and Y on some host.” (Also the inability to control holds and such.) Well I wish you gentlemen success. It seems that you already have quite a useful tool to work with. Any ideas how it could synchronize with the periodic apt script that performs update, clean, etc.? From our experience there is an inherent problem between multiple tools handling automatic package list updates and package upgrades stepping on each others toes. Indeed. But our discussion about how to reply to this question just gave us the idea that we may be able to run aptitude-robot triggered by apt periodic. We'll investigate this idea. If only it had a hook to run post-update and pre-clean … From aptitude-robot-session: # yes forces the default answer to any configuration question nice yes | /usr/sbin/aptitude-robot Have you considered something more explicit, such as: # aptitude -y -o DPkg::Options::=--force-confdef \ -o DPkg::Options::=--force-confold … Good point! Thanks. Note that the dpkg options are ignored when aptitude tries “dpkg --configure -a” to fix a failed install. https://bugs.launchpad.net/bugs/257279 Regards -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAN3veRfuzjnjMxqUQ3jnBq6mmoNwOUSGxJAMKxRZ+=nrg-e...@mail.gmail.com
Processed (with 1 errors): taking this gem
Processing commands for cont...@bugs.debian.org: owner 622654 Praveen prav...@debian.org Bug #622654 [wnpp] ITP: vegas -- Vegas aims to solve the simple problem of creating executable versions of Sinatra/Rack apps Owner changed from Ankit Gupta ankitgupta...@gmail.com to Praveen prav...@debian.org. retitle 622654 ITP: ruby-vegas -- create executable versions of Bug #622654 [wnpp] ITP: vegas -- Vegas aims to solve the simple problem of creating executable versions of Sinatra/Rack apps Changed Bug title to 'ITP: ruby-vegas -- create executable versions of' from 'ITP: vegas -- Vegas aims to solve the simple problem of creating executable versions of Sinatra/Rack apps' Sinatra/Rack apps Unknown command or malformed arguments to command. -- Stopping processing here. Please contact me if you need assistance. -- 622654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135307837225399.transcr...@bugs.debian.org
Processed: retitle 622654 to ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps
Processing commands for cont...@bugs.debian.org: retitle 622654 ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps Bug #622654 [wnpp] ITP: ruby-vegas -- create executable versions of Changed Bug title to 'ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps' from 'ITP: ruby-vegas -- create executable versions of' thanks Stopping processing here. Please contact me if you need assistance. -- 622654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135307909230192.transcr...@bugs.debian.org
Processed: retitle 622654 to ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps
Processing commands for cont...@bugs.debian.org: retitle 622654 ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps Bug #622654 [wnpp] ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps Ignoring request to change the title of bug#622654 to the same title thanks Stopping processing here. Please contact me if you need assistance. -- 622654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622654 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135307949432676.transcr...@bugs.debian.org
Processed (with 1 errors): your mail
Processing commands for cont...@bugs.debian.org: owner 692563 mar...@kotsbak.com Bug #692563 [wnpp] RFP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications. Owner recorded as mar...@kotsbak.com. retitle 692563 ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable Bug #692563 [wnpp] RFP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications. Changed Bug title to 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable' from 'RFP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications.' IPC/RPC middleware framework for C++ applications Unknown command or malformed arguments to command. End of message, stopping processing here. Please contact me if you need assistance. -- 692563: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692563 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13530803336283.transcr...@bugs.debian.org
Processed (with 1 errors): Fix title caused by e-mail line break
Processing commands for cont...@bugs.debian.org: retitle 692563 ITP: librcf-cpp -- Remote Call Framework (RCF) is a Bug #692563 [wnpp] ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable Changed Bug title to 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a' from 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable' portable IPC/RPC middleware framework for C++ applications Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. -- 692563: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692563 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135308299524509.transcr...@bugs.debian.org
Bug#693451: RFP: pycessing -- python based educational programming environment like processing
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: pycessing Version : 0.2.1 Upstream Author : Brendan Howell * URL : http://pycessing.org * License : GPL3+ Programming Lang: Python Description : python based educational programming environment like processing Pycessing is an educational programming environment that makes it easy for the student to produce graphics and do other motivational things. It's modelled after the java based processing[1]. [1] http://processing.org @Brendan: I want to look at pycessing and probably package it for Debian. (It'll then also be available for all Debian based distributions e.g. Ubuntu). I see that there are many commits in the Git repository on bitbucket in 2012 but no release since 2011. Could you do a release in the next weeks? Regards, Thomas Koch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQpm6LAAoJEAf8SJEEK6ZaMnUQAMCy3qoWfYKDEAptGwuj1Dgl KzUqZAbRvDXXs605GWIb2Aeg8yOB+neE3a666GqXfSyBFI5KqyLSF0+bzLNvzhty a7M4PfaKTJsjVmwoKaPoUXJ9ZQfOrXy6sqc851HupBdjkfU10e6so5a/ocwsqmC8 02uDJfg6RvbHkbwTo3jhL+3HlMG/sPtkDB7zoW6BEHQUAW7rOamCG3xVW7eiOQKA 7Pjdwf7lFhRwz4fOfzMrn9uQxese1CuQva3BLpoiZ5NGfwYMoViYCkvhrcv4tbAH 0WSCm064As6IpvVMOZY2U0iqNFNshHri0ggqSzfkmcQjACqVyKA2jSx0xrUbd/Jy Z0YJ3rqD7+C/itXdenqXzCpoXhVYIv/tGb0ON3hauoqtoqhWXCdnBvbTFHBXUkUK E+VD3ASAFdpehhQXw7n/AjWr6Lxv8vytv+PyanjFvN6VFEzQwDoEfpxRjGZYliJ4 0VCBUp+f7R4TrC3K4loHOMLBbzU5+jpNXMNnZTLjhF/LsXYrFtqQcAdmmlWr32B1 Fq3OCQTLmLrgyJoym0vTQK9NzP/YIe+bAQ/SB0r7OpzjkTKKblF9UNdn31MhpYQ7 OSBS4eQsYfvfEwVpAjMsz5YRwORFaLxakLuEQV0NJW4Fm5kWMsCIsRduwcdrm7iZ eQ5t3v9jGyE5Le1Ea8uo =77fg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116164922.22503.85979.reportbug@x121e
Processed: Fix title caused by e-mail line break again
Processing commands for cont...@bugs.debian.org: retitle 692563 ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications Bug #692563 [wnpp] ITP: librcf-cpp -- Remote Call Framework (RCF) is a Changed Bug title to 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications' from 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a' thanks Stopping processing here. Please contact me if you need assistance. -- 692563: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692563 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13530844721590.transcr...@bugs.debian.org
Processed: Remove quotation
Processing commands for cont...@bugs.debian.org: retitle 692563 ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications Bug #692563 [wnpp] ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications Changed Bug title to 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications' from 'ITP: librcf-cpp -- Remote Call Framework (RCF) is a portable IPC/RPC middleware framework for C++ applications' thanks Stopping processing here. Please contact me if you need assistance. -- 692563: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692563 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13530848484122.transcr...@bugs.debian.org
Bug#642208: ITP: opengtl -- Set of library for using transformation algorithms
Hi, Is there any news on the packaging of opengtl since september 2011 ? Regards, Adrien -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201211161902.20004.adrien.grell...@laposte.net
Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for cont...@bugs.debian.org: # Friday 16 November 19:03:14 UTC 2012 # Tagging as pending bugs that are closed by packages in NEW # http://ftp-master.debian.org/new.html # # Source package in NEW: ruby-vegas tags 622654 + pending Bug #622654 [wnpp] ITP: ruby-vegas -- create executable versions of Sinatra/Rack apps Added tag(s) pending. # Source package in NEW: a href=http://packages.qa.debian.org/libcec;libcec/a tags 685058 + pending Bug #685058 [libcec] New upstream release Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 622654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622654 685058: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685058 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135309260029325.transcr...@bugs.debian.org
Bug#659632: Review of the graphite-web package
* Mathieu Parent math.par...@gmail.com, 2012-11-15, 15:18: I have packaged my first python package. I have read the Debian Python Policy , but I need a review from the experts here ;-) A few hints regarding seeking sponsorship: 1) Tell us exactly where can we get your package: give us a link to .dsc or a VCS URL. 2) Nobody reads python-*-t...@lists.alioth.debian.org; debian-pyt...@lists.debian.org might be a better place to ask. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121116210230.ga2...@jwilk.net
Bug#693481: ITP: python-webm -- python interface to the Google WebM video/image codec
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: python-webm Version: 0.2.2 Upstream Author: Daniele Esposti e...@expobrain.net URL: https://code.google.com/p/python-webm License: BSD-2-clause (modified) Description: python interface to the Google WebM video/image codec The interface uses ctypes to call the libvpx/libwebm Google signature.asc Description: This is a digitally signed message part.
Processed: owner 693481
Processing commands for cont...@bugs.debian.org: owner 693481 ! Bug #693481 [wnpp] ITP: python-webm -- python interface to the Google WebM video/image codec Owner recorded as Dmitry Smirnov only...@member.fsf.org. thanks Stopping processing here. Please contact me if you need assistance. -- 693481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693481 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135310764431544.transcr...@bugs.debian.org
Bug#692830: nemo
What degree of separation is required before a fork becomes non-redundant? How is this evaluated? You have provided some valid reasoning against including mdm in its current state, however that is off the topic of this thread. A substantial amount of work has gone into Nemo since it was forked some months ago - 184 in my count (granted, a number of those are merges) - and it is currently under active development. Nemo is integral to Cinnamon, part of the intended User Experience, and becoming more-so every day. Hopefully this 'decision' is given a bit more thought and consideration... and feel free to try it out before issuing a blanket dismissal and a 'just use Nautilus' response. Thanks
Bug#693492: ITP: litecoin -- peer-to-peer network based digital currency
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: litecoin Version: 0.6.3c Upstream Author: Litecoin Developers URL: https://github.com/litecoin-project/litecoin License: MIT/X11, ISC Description: peer-to-peer network based digital currency Litecoin is a free open source peer-to-peer electronic cash system that is completely decentralized, without the need for a central server or trusted parties. Users hold the crypto keys to their own money and transact directly with each other, with the help of a P2P network to check for double-spending. Litecoin is a fork of Bitcoin. signature.asc Description: This is a digitally signed message part.
Processed: wmtime: block ITA 691813 by RFS 693495
Processing commands for cont...@bugs.debian.org: block 691813 by 693495 Bug #691813 [wnpp] ITA: wmtime -- Window Maker dockapp that displays the time and date 691813 was not blocked by any bugs. 691813 was not blocking any bugs. Added blocking bug(s) of 691813: 693495 stop Stopping processing here. Please contact me if you need assistance. -- 691813: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135312603719473.transcr...@bugs.debian.org
Processed: ITP: litecoin -- peer-to-peer network based digital currency
Processing commands for cont...@bugs.debian.org: owner 693492 Dmitry Smirnov only...@member.fsf.org Bug #693492 [wnpp] ITP: litecoin -- peer-to-peer network based digital currency Owner recorded as Dmitry Smirnov only...@member.fsf.org. stop Stopping processing here. Please contact me if you need assistance. -- 693492: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693492 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.135312602019235.transcr...@bugs.debian.org
