Bug#718580: ITP: mayan -- Django-based Electronic Document Management System (EDMS)
Hi Mathias! On 2014-02-02 at 14:00, Mathias Behrle mathi...@m9s.biz wrote: I am just starting to use mayan and I want to ask, if there are already some results for this ITP. This only to give feedback, that I am interested to have this package in Debian as well. Actually, the packaging is in stall because some of the build dependencies aren't available as independent packages in Debian. There were a couple of Python modules that prevented me to start working seriously on Mayan. I discovered that Python environments are not allowed (or, at least, appreciated) in Debian packaging. So I need to understand even that part of the process. Given that, if you are in a hurry for using Mayan, then you'd better start breathing again and use the python-env system for now. I'll keep you updated on the progresses I may achieve with this package, if you are interested in this task. Cheers. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID: 0x83B2CF7A signature.asc Description: Digital signature
Bug#389591: ITP: freeswitch -- Modular Media Switching Software Library and Soft-Switch Application
Hello William, Ken. It's been more than 2 years ago when this debian bug #389591 has been update for the last time, changing its status from RFP to ITP (request for packaging into intention to package). Has anything changed since that time? I'm trying to run freeswitch on debian now, but it seems it is still in very far from acceptable state, because of the habit of embedding 3rd party libraries when needed or not. I can try to clean some of that up (for example, libtiff, pcre, ldns, curl, speex, opus, ldap - at least - should be easy to replace with system (debian-provided) libs), but if something is already done, maybe I may try to use that instead of re-doing things again. Or are there no plans to make the software within linux distributions exist anymore, or maybe that's a bad idea somehow? (Yes I've read recent (and not so recent) posts about embedding 3rd party libs into the distribution). Thanks, /mjt -- 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/52ef5151.9030...@msgid.tls.msk.ru
Bug#737500: ITP: arbiterjs - client-side pub/sub JavaScript library
Package: wnpp Severity: wishlist Owner: Daniel Pocock dan...@pocock.com.au Upstream: http://arbiterjs.com License: MIT or GPL Allows pub/sub interaction (loose coupling) between JavaScript modules in a web page. -- 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/52ef5705.7080...@pocock.com.au
Processed: your mail
Processing commands for cont...@bugs.debian.org: retitle 546754 ITP: ruby-numru-units -- Class library handling units of physical quantities Bug #546754 [wnpp] ITP: numru-units -- Class library handling units of physical quantities Changed Bug title to 'ITP: ruby-numru-units -- Class library handling units of physical quantities' from 'ITP: numru-units -- Class library handling units of physical quantities' owner 546754 ! Bug #546754 [wnpp] ITP: ruby-numru-units -- Class library handling units of physical quantities Ignoring request to set the owner of bug #546754 to the same value thanks Stopping processing here. Please contact me if you need assistance. -- 546754: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546754 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.139142242411668.transcr...@bugs.debian.org
Bug#737524: ITP: php5-igbinary -- igbinary extension
Package: wnpp Severity: wishlist Owner: Mathieu Parent math.par...@gmail.com Package name: igbinary Version : 1.1.1 Upstream Author : Pierre Joye, Teddy Grenman URL : http://pecl.php.net/ License : PHP like license Programming Lang: PHP Description : igbinary extension Igbinary is a drop in replacement for the standard php serializer. Instead of time and space consuming textual representation, igbinary stores php data structures in a compact binary form. Savings are significant when using memcached or similar memory based storages for serialized data. I'm packaging this as part of Horde5 packaging. -- 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/e1wajqv-00080f...@tourthieu.sathieu.net
Bug#737523: ITP: php5-msgpack -- PHP extension for interfacing with MessagePack
Package: wnpp Severity: wishlist Owner: Mathieu Parent math.par...@gmail.com Package name: msgpack Version : 0.5.5 Upstream Author : Advect, Xinchen Hui URL : http://pecl.php.net/ License : New BSD Programming Lang: PHP Description : PHP extension for interfacing with MessagePack This extension provide API for communicating with MessagePack serialization. I'm packaging this as part of Horde5 packaging. -- 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/e1wajqu-0007zm...@tourthieu.sathieu.net
Processed: Re: [pkg-horde] Bug#737257: php-horde-pack: recommends packages not in the archive
Processing control commands: block -1 by 737523 737524 Bug #737257 [src:php-horde-pack] php-horde-pack: recommends packages not in the archive 737257 was not blocked by any bugs. 737257 was not blocking any bugs. Added blocking bug(s) of 737257: 737523 and 737524 -- 737257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737257 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.b737257.13914357067603.transcr...@bugs.debian.org
Bug#737533: ITP: r-cran-rnetcdf -- GNU R package that provides an R Interface to NetCDF Datasets
Package: wnpp Severity: wishlist Owner: Sebastian Gibb sgibb.deb...@gmail.com * Package name: r-cran-rnetcdf Version : 1.6.1-2 Upstream Author : Pavel Michna mic...@giub.unibe.ch * URL : http://cran.r-project.org/web/packages/RNetCDF/index.html * License : GPL=2 Programming Lang: R Description : GNU R package that provides an R Interface to NetCDF Datasets This package provides an interface to Unidata's NetCDF library functions (version 3) and furthermore access to Unidata's UDUNITS calendar conversions. -- 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/20140203145908.5040.56677.report...@tp.fritz.box
Bug#389591: ITP: freeswitch -- Modular Media Switching Software Library and Soft-Switch Application
There is work to enable use of system libs for some of these things. There are others that wont happen at all ie: sofia-sip and spandsp... Patches are welcome and you are welcome to join us on the weekly FreeSWITCH conference calls to discuss this with the other devs to avoid duplication of efforts. On 2/3/14 2:20 AM, Michael Tokarev m...@tls.msk.ru wrote: Hello William, Ken. It's been more than 2 years ago when this debian bug #389591 has been update for the last time, changing its status from RFP to ITP (request for packaging into intention to package). Has anything changed since that time? I'm trying to run freeswitch on debian now, but it seems it is still in very far from acceptable state, because of the habit of embedding 3rd party libraries when needed or not. I can try to clean some of that up (for example, libtiff, pcre, ldns, curl, speex, opus, ldap - at least - should be easy to replace with system (debian-provided) libs), but if something is already done, maybe I may try to use that instead of re-doing things again. Or are there no plans to make the software within linux distributions exist anymore, or maybe that's a bad idea somehow? (Yes I've read recent (and not so recent) posts about embedding 3rd party libs into the distribution). Thanks, /mjt -- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH -- 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/cf150d18.760c7%kr...@freeswitch.org
Bug#729203: CTTE and reasonable solutions
On Fri, 10 Jan 2014 18:52:06 +0200, Adrian Bunk wrote: On Fri, Jan 10, 2014 at 08:17:45AM +0100, Lorenzo Sutton wrote: Agree with many on at least providing the *option* for users to have the original ffmpeg instead of libav and using sensible clear names and descriptions for both packages. ... Without getting into the politics of the fork etc. users should be able to do apt-get install ffmpeg or apr-get install libav ... It is a misconception that making this optional would be a reasonable solution - in reality the hassle that would create would is so huge that no sane person would want to implement the packaging for something like that. Doing that for local use might not be too hard, but doing it 100% correct for a Debian release is simply not feasible. Can you clarify why this is not possible? The library names of ffmpeg and libav now seem perfectly orthogonal and it seems to me it should be possible to ship Jessie with both libav and ffmpeg if someone would be willing to package the latter. It turns out that this is exactly what this bug report is about: we have one brave soul that is volunteering for that effort. He has also clearly stated why libav doesn't respond to his requirements. If you have objections against ffmpeg being packaged in Debian, I suggest you clarify those instead of requiring Rogério to address the CTTE right away, which seems to me a little abusive. Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. A. -- Non qui parum habet, sed qui plus cupit, pauper est. It is not the man who has too little, but the man who craves more, that is poor.- Lucius Annaeus Seneca (65 AD) signature.asc Description: Digital signature
Bug#737546: ITP: bquery -- simple cli tool to quickly parse html streams with a jQuery-like expression
Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) gand...@le-vert.net * Package name: bquery Version : 0.1 Upstream Author : mont5piques newis...@gmail.com * URL : https://github.com/mont5piques/bquery * License : WTFPL Programming Lang: Python Description : simple cli tool to quickly parse html streams with a jQuery-like expression bQuery is powefull command line client based on PyQuery. . It can be used in combination of grep and wget (ie) to do some magic using jQuery style expressions. . In example, it can download any .tar.gz files from a webpage by filtering on href links (see manpage). -- 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/20140203164707.19236.21177.reportbug@thrall.courc.levert
Bug#729203: CTTE and reasonable solutions
On Mon, Feb 03, 2014 at 10:33:17AM -0500, anarcat wrote: On Fri, 10 Jan 2014 18:52:06 +0200, Adrian Bunk wrote: On Fri, Jan 10, 2014 at 08:17:45AM +0100, Lorenzo Sutton wrote: Agree with many on at least providing the *option* for users to have the original ffmpeg instead of libav and using sensible clear names and descriptions for both packages. ... Without getting into the politics of the fork etc. users should be able to do apt-get install ffmpeg or apr-get install libav ... It is a misconception that making this optional would be a reasonable solution - in reality the hassle that would create would is so huge that no sane person would want to implement the packaging for something like that. Doing that for local use might not be too hard, but doing it 100% correct for a Debian release is simply not feasible. Can you clarify why this is not possible? The library names of ffmpeg and libav now seem perfectly orthogonal and it seems to me it should be possible to ship Jessie with both libav and ffmpeg if someone would be willing to package the latter. It turns out that this is exactly what this bug report is about: we have one brave soul that is volunteering for that effort. He has also clearly stated why libav doesn't respond to his requirements. If you have objections against ffmpeg being packaged in Debian, I suggest you clarify those instead of requiring Rogério to address the CTTE right away, which seems to me a little abusive. Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. Can you clarify whether you are sincerely asking for clarification, or whether that would be pointless since you've anyway already decided that everything I write are flames and anything I'll answer you'll only use for further attacks against me? A. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140203171845.ge26...@bunk.dyndns.info
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 12:18:45, Adrian Bunk wrote: Can you clarify whether you are sincerely asking for clarification, or whether that would be pointless since you've anyway already decided that everything I write are flames and anything I'll answer you'll only use for further attacks against me? It is interesting that you feel specifically targeted when I mention flames whereas I haven't specifically mentionned you were the source of the heat. There were numerous messages in this bug report so far and a number of them have been out of line. I would prefer if you would assume I was asking in good faith, in general. So yes, I am genuinely asking for clarification. A. -- À force de ne jamais réfléchir, on a un bonheur stupide - Jean Cocteau pgpy4l1tM2sib.pgp Description: PGP signature
Bug#737561: ITP: health-check -- process monitoring tool
Package: wnpp Severity: wishlist Owner: Colin Ian King colin.k...@canonical.com * Package name: health-check Version : 0.01.50 Upstream Author : Colin King colin.k...@canonical.com * URL : http://kernel.ubuntu.com/~cking/health-check * License : GPL-2 Programming Lang: C Description : process monitoring tool Health-check monitors a processes and optionally their child processes and threads for a given amount of time. At the end of the monitoring it will log the CPU time used, wakeup events generated and I/O operations of the given processes. It can be used to diagnose unhealthy bad processes. -- 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/20140203185638.14926.47062.reportbug@lenovo
Processed: block 736353 with 701962
Processing commands for cont...@bugs.debian.org: block 736353 with 701962 Bug #736353 [zeromq3] zeromq3: Add zeromq 4.0.3 736353 was not blocked by any bugs. 736353 was not blocking any bugs. Added blocking bug(s) of 736353: 701962 thanks Stopping processing here. Please contact me if you need assistance. -- 736353: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736353 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.139145512321755.transcr...@bugs.debian.org
Bug#737563: ITP: telegram-cli -- Command-line interface for Telegram
Package: wnpp Severity: wishlist Owner: Cleto Martín cl...@debian.org * Package name: telegram-cli Version : 0.1 Upstream Author : Vitaly Valtman * URL : https://github.com/vysheng/tg * License : GPL Programming Lang: C Description : Command-line interface for Telegram messenger Telegram messenger is a cloud-based instant messaging platform designed for smart phones and similar to Whatsapp but more flexible, and powerful. You can send messages, photos, videos and documents to people who are in your phone contacts (and have Telegram). Telegram also supports secret chats whose provide a private (encrypted) way of communication. . This package contains a command-line based client for Telegram with the following features: * Colored terminal messages. * Message management: history, stats, etc. * Group chat: create and manage groups. * Secret chat: secured and encrypted conversations. * Contact management: add/edit/remove contacts. * Multimedia support: send/load photos and videos. -- 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/20140203205241.10439.51219.reportbug@brian
Bug#737566: ITP: python-fitbit -- Python module for querying the FitBit REST API
Package: wnpp Severity: wishlist Owner: Iain R. Learmonth i...@fsfe.org * Package name: python-fitbit Version : 0.0.2 Upstream Author : ORCAS i...@orcasinc.com * URL : https://github.com/orcasgit/python-fitbit * License : Apache Programming Lang: Python Description : Python module for querying the FitBit REST API A Python module containing an implementation of a client for the FitBit REST API. It uses oAuth for authentication, it supports both US and SI units. . This package complements the python3-fitbitscraper that is currently sitting in the new queue. It talks to the REST API instead of scraping the website providing a wider range of data than python3-fitbitscraper but with a lower time resolution. . This is being packaged as part of the Tools task of the Debian-Med Blend. -- 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/20140203211539.30012.54365.report...@axiom.shiftout.net
Bug#729203: CTTE and reasonable solutions
On Mon, Feb 03, 2014 at 12:48:45PM -0500, Antoine Beaupré wrote: On 2014-02-03 12:18:45, Adrian Bunk wrote: Can you clarify whether you are sincerely asking for clarification, or whether that would be pointless since you've anyway already decided that everything I write are flames and anything I'll answer you'll only use for further attacks against me? It is interesting that you feel specifically targeted when I mention flames whereas I haven't specifically mentionned you were the source of the heat. There were numerous messages in this bug report so far and a number of them have been out of line. I would prefer if you would assume I was asking in good faith, in general. You used flames in an email directly answering to me, and in a sentence where you told someone to go ahead without even waiting for the clarification you just asked from me. You should re-read how that sounded to me. So yes, I am genuinely asking for clarification. First of all, your The library names of ffmpeg and libav now seem perfectly orthogonal is AFAIK not completely true, e.g. libswscale still seems to have the same soname in both projects. So you might end up mixing libav and ffmpeg libraries, and I wouldn't be sure that this would work smoothly in all cases. And if it would be true, then something like the suggested apt-get install ffmpeg would simply not do at all what was implied it would do. Let me use VLC as example: VLC (maintained by the same Debian multimedia maintainers as libav) is using the libav libraries, and therefore depends on them. When all libav libraries used by VLC have sonames different from the sonames of the ffmpeg libraries, then VLC will always use the libav libraries and never use any ffmpeg libraries at all. If all you expect to happen after apt-get install ffmpeg is that there is an ffmpeg binary that is using the ffmpeg libraries, then this might be doable. But if someone wants, as Lorenzo suggested, an apt-get install ffmpeg to magically switch all applications like VLC from using libav to ffmpeg, then one of the requirements for that would clearly be that there would have to be two versions of all binaries and libraries using libav/ffmpeg in the archive - one compiled with libav, and one compiled with ffmpeg. That would be technically insane, and politically impossible unless CTTE (or a GR) would override the likely veto from the Debian multimedia maintainers for doing that in any of the packages they maintain. A. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140203212238.gf26...@bunk.dyndns.info
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 16:22:38, Adrian Bunk wrote: On Mon, Feb 03, 2014 at 12:48:45PM -0500, Antoine Beaupré wrote: On 2014-02-03 12:18:45, Adrian Bunk wrote: Can you clarify whether you are sincerely asking for clarification, or whether that would be pointless since you've anyway already decided that everything I write are flames and anything I'll answer you'll only use for further attacks against me? It is interesting that you feel specifically targeted when I mention flames whereas I haven't specifically mentionned you were the source of the heat. There were numerous messages in this bug report so far and a number of them have been out of line. I would prefer if you would assume I was asking in good faith, in general. You used flames in an email directly answering to me, and in a sentence where you told someone to go ahead without even waiting for the clarification you just asked from me. You should re-read how that sounded to me. I am sorry you felt targeted, that was not my intention. So yes, I am genuinely asking for clarification. First of all, your The library names of ffmpeg and libav now seem perfectly orthogonal is AFAIK not completely true, e.g. libswscale still seems to have the same soname in both projects. So you might end up mixing libav and ffmpeg libraries, and I wouldn't be sure that this would work smoothly in all cases. I didn't know libswscale still had the same soname, but then I only summarily looked at the package contents. And if it would be true, then something like the suggested apt-get install ffmpeg would simply not do at all what was implied it would do. I would assume it would imply installing ffmpeg. :) Let me use VLC as example: VLC (maintained by the same Debian multimedia maintainers as libav) is using the libav libraries, and therefore depends on them. When all libav libraries used by VLC have sonames different from the sonames of the ffmpeg libraries, then VLC will always use the libav libraries and never use any ffmpeg libraries at all. If all you expect to happen after apt-get install ffmpeg is that there is an ffmpeg binary that is using the ffmpeg libraries, then this might be doable. I think that would be a fair expectation. But if someone wants, as Lorenzo suggested, an apt-get install ffmpeg to magically switch all applications like VLC from using libav to ffmpeg, then one of the requirements for that would clearly be that there would have to be two versions of all binaries and libraries using libav/ffmpeg in the archive - one compiled with libav, and one compiled with ffmpeg. I reread Lorenzo's email, and it doesn't actually say switch all applications like VLC from libav to ffmpeg. He just said: users should be able to do apt-get install ffmpeg or apr-get install libav I think some people here are talking about using ffmpeg as a commandline-based conversion tool, not necessarily the way you are bringing up, as a library that (say) vlc is linking against. That would be technically insane, and politically impossible unless CTTE (or a GR) would override the likely veto from the Debian multimedia maintainers for doing that in any of the packages they maintain. Then maybe this RFP can focus on providing the ffmpeg binary again and not necessarily get into replacing libav altogether, which I think was the original intention here, hence my original email. :) Cheers, A. -- Ce que les siècles des grands abatoirs nous aura appris Devrait être inscrit au fond de toutes les écoles; Voici l'homme: le destructeur des mondes est arrivé. - [no one is innocent] pgpntG4ToWH5V.pgp Description: PGP signature
Processed: retitle 710378 to ITP: libevhtp -- libevent based HTTP API, submitter 710378
Processing commands for cont...@bugs.debian.org: retitle 710378 ITP: libevhtp -- libevent based HTTP API Bug #710378 [wnpp] RFP: libevhtp -- libevent based HTTP API Changed Bug title to 'ITP: libevhtp -- libevent based HTTP API' from 'RFP: libevhtp -- libevent based HTTP API' submitter 710378 ! Bug #710378 [wnpp] ITP: libevhtp -- libevent based HTTP API Changed Bug submitter to 'Vincent Bernat ber...@debian.org' from 'Dennis van Dok denni...@nikhef.nl' thanks Stopping processing here. Please contact me if you need assistance. -- 710378: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710378 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.139146463224189.transcr...@bugs.debian.org
Bug#729203: CTTE and reasonable solutions
First of all, thank you very much for CC'ing me, as I am not receiving
things from this bug report (despite having tried to subscribe to the bug).
On Feb 03 2014, anarcat wrote:
On Fri, 10 Jan 2014 18:52:06 +0200, Adrian Bunk wrote:
It is a misconception that making this optional would be a reasonable
solution - in reality the hassle that would create would is so huge
that no sane person would want to implement the packaging for something
like that.
Doing that for local use might not be too hard, but doing it 100%
correct for a Debian release is simply not feasible.
Can you clarify why this is not possible? The library names of ffmpeg
and libav now seem perfectly orthogonal and it seems to me it should be
possible to ship Jessie with both libav and ffmpeg if someone would be
willing to package the latter.
As Antoine mentioned, with good intentions, it is possible to ship ffmpeg in
Debian in time for the release of jessie. The problem is that there may not
be as many good intentions and the wish to work jointly to make this happen,
which is another matter completely (otherwise, why have the libav fork in
the first place?).
It turns out that this is exactly what this bug report is about: we have
one brave soul that is volunteering for that effort. He has also clearly
stated why libav doesn't respond to his requirements.
Indeed, some people say that I like to work on packaging some hard to crack
packages (like handbrake, which required me to, essentially, patch the hell
out of it to make it compile and work work with Debian's libav and to avoid
the abundant use of embedded libraries; or the packaging of mongodb, which
was, essentially, dormant for some time, with bazillion embedded libraries
again, being used---it now has found some good hands to maintain it).
Regarding libav, it really, really falls short on many places in comparison
with ffmpeg. I can list features that it today, but they will be implemented
(well, some not) and, then, ffmpeg will have moved on with further useful
features that will be missing from libav and so on.
If you have objections against ffmpeg being packaged in Debian, I suggest
you clarify those instead of requiring Rogério to address the CTTE right
away, which seems to me a little abusive.
Indeed, seeing the whole init system decision (which I have been following
*every* single day quietly), I can only think that some (not all) can not
really judge the technical merits of some software.
Furthermore, technical excellence (even in the ideal case or in the more
pragmatic sense of well, it is not perfect, but it provides working
features that people really *need*) is being left behind with the current
decisions that Debian has taken.
Rogério, I would suggest you go ahead with the packaging and an upload,
don't let the flames fan your enthousiasm.
Thanks for the encouragement, Antoine. I am mostly paralized with this
situation and I don't really know how to proceed. I think that the forces of
having to potentially fight the tech-ctte, the pkg-multimedia-team, the
ftp-masters and some other people is that is preventing me right now from
packaging ffmpeg all by myself.
If other people join me in the work (and, most importantly, the
argumentation---well, the ffmpeg upstream team has been wonderfully
supportive of the initiative), then I may go on and package this thing.
Thanks for the support,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
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/20140203221343.ga30...@ime.usp.br
Bug#702075: ITP: hexchat -- an IRC client based on XChat
retitle 702075 ITP: hexchat -- an IRC client based on XChat owner 702075 ! thanks Hi, I have been using hexchat daily (which I packaged myself) and since it seems nobody else is interested in maintaining it, I volunteer. Jesse Rhodes -- 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/cad_06eukbbx0vpv7+t+rq6b-tvcm5o4o3q2o-ws5+4s5woz...@mail.gmail.com
Processed: ITP: hexchat -- an IRC client based on XChat
Processing commands for cont...@bugs.debian.org: retitle 702075 ITP: hexchat -- an IRC client based on XChat Bug #702075 [wnpp] RFP: hexchat -- an IRC client based on XChat Changed Bug title to 'ITP: hexchat -- an IRC client based on XChat' from 'RFP: hexchat -- an IRC client based on XChat' owner 702075 ! Bug #702075 [wnpp] ITP: hexchat -- an IRC client based on XChat Owner recorded as Jesse Rhodes dr...@drubo.net. thanks Stopping processing here. Please contact me if you need assistance. -- 702075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702075 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.13914659932219.transcr...@bugs.debian.org
Bug#729203: CTTE and reasonable solutions
On Mon, Feb 03, 2014 at 04:32:49PM -0500, Antoine Beaupré wrote: On 2014-02-03 16:22:38, Adrian Bunk wrote: ... But if someone wants, as Lorenzo suggested, an apt-get install ffmpeg to magically switch all applications like VLC from using libav to ffmpeg, then one of the requirements for that would clearly be that there would have to be two versions of all binaries and libraries using libav/ffmpeg in the archive - one compiled with libav, and one compiled with ffmpeg. I reread Lorenzo's email, and it doesn't actually say switch all applications like VLC from libav to ffmpeg. He just said: users should be able to do apt-get install ffmpeg or apr-get install libav I think some people here are talking about using ffmpeg as a commandline-based conversion tool, not necessarily the way you are bringing up, as a library that (say) vlc is linking against. Before what you quote he said in the same email: Agree with many on at least providing the *option* for users to have the original ffmpeg instead of libav There is no libav program, and he is clearly talking about the libraries. That would be technically insane, and politically impossible unless CTTE (or a GR) would override the likely veto from the Debian multimedia maintainers for doing that in any of the packages they maintain. Then maybe this RFP can focus on providing the ffmpeg binary again and not necessarily get into replacing libav altogether, which I think was the original intention here, hence my original email. :) No. Rogério is listing in the initial email in this RFP many reasons for the ffmpeg libraries. But he never mentions anything related to the ffmpeg commandline programs. Or are you seriously saying chromium would use the ffmpeg commandline programs? The ffmpeg/libav commandline programs are relatively rarely used - what is used heavily on Linux are the libraries. Cheers, A. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140203222540.gg26...@bunk.dyndns.info
Bug#729203: CTTE and reasonable solutions
On Mon, Feb 03, 2014 at 08:13:43PM -0200, Rogério Brito wrote: ... Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. Thanks for the encouragement, Antoine. I am mostly paralized with this situation and I don't really know how to proceed. I think that the forces of having to potentially fight the tech-ctte, the pkg-multimedia-team, the ftp-masters and some other people is that is preventing me right now from packaging ffmpeg all by myself. If other people join me in the work (and, most importantly, the argumentation---well, the ffmpeg upstream team has been wonderfully supportive of the initiative), then I may go on and package this thing. ... You do know that ffmpeg and gazillions of programs like vlc and handbrake compiled against ffmpeg are already packaged in the usual external repository? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140203225032.gh26...@bunk.dyndns.info
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:25:40, Adrian Bunk wrote: Before what you quote he said in the same email: Agree with many on at least providing the *option* for users to have the original ffmpeg instead of libav There is no libav program, and he is clearly talking about the libraries. I assumed libav included programs, and that is also what the wikipedia article says. But maybe lorenzo can tell better what he meant than us. I certainly mean that we could provide the program. That would be technically insane, and politically impossible unless CTTE (or a GR) would override the likely veto from the Debian multimedia maintainers for doing that in any of the packages they maintain. Then maybe this RFP can focus on providing the ffmpeg binary again and not necessarily get into replacing libav altogether, which I think was the original intention here, hence my original email. :) No. Rogério is listing in the initial email in this RFP many reasons for the ffmpeg libraries. But he never mentions anything related to the ffmpeg commandline programs. He did mention he wanted to package ffmpeg as a replacement of libav, I stand corrected. Or are you seriously saying chromium would use the ffmpeg commandline programs? Now where did I ever mention chrome? The ffmpeg/libav commandline programs are relatively rarely used - what is used heavily on Linux are the libraries. I guess my use case is different then. Certainly there's a use case for the ffmpeg program just working properly in the first place. Taking a step back, there seems to be a lot of frustrations flying around that issue, maybe it would be better to keep an open mind and try to fix issues here. One of the proposals on the table is to bring back ffmpeg, at least as a program, possibly as a library. You seem to be saying that is insane, but I fail to see the technical reasons behind that argument, other than debian-multimedia vetoing it. Maybe that discussion should be taken there then? I see there was one email about ffmpeg on the mailing list about a month ago, without any response, but that's all... What's your proposal to fix the problems with libav mentionned in this thread? What's your response to the claims that ffmpeg is a superset of libav and that libav is lagging in development? If ffmpeg is technically superior and compatible with libav, why shouldn't we package it? I feel there's a knee-jerk reaction against the inclusion of ffmpeg here, and I don't understand the technical reasons for that. Certainly we could offer ffmpeg as a replacement (Conflicts: Replaces:) of libav and people could choose between the two, especially if libav is such a drop-in replacement for packages that depend on ffmpeg... I think any Debian Developper is perfectly entitled to work on a ffmpeg package, upload it to new and let the FTP masters decide what to do with it. Now of course to make other packages use its libraries is a matter that should be left to those other package's maintainers, that's a different story, and not the topic of this RFP, from what I understand. A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm pgpaVMVzeLHU3.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:13:43, Rogério Brito wrote: Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. Thanks for the encouragement, Antoine. I am mostly paralized with this situation and I don't really know how to proceed. I think that the forces of having to potentially fight the tech-ctte, the pkg-multimedia-team, the ftp-masters and some other people is that is preventing me right now from packaging ffmpeg all by myself. I am not sure you should fight anyone here. Do the package, may it policy-clean and it will pass NEW. If someone wants to bring up something with the ctte, they can do it, but you don't have to right now. Having a discussion on pkg-multimedia may be necessary if other package dependencies should be changed, and it is probably good practice to discuss this topic on that mailing list, but it seems to me that people shouldn't object to the inclusion of another package in debian solely on the ground that they do not like it. If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. We have a policy for such procedures. Our social contract also says we should respond to the needs of users, and the overwhelming majority of people on this issue have voiced their need for a working ffmpeg implementation in Debian. We should respond to that. A. -- From the age of uniformity, from the age of solitude, from the age of Big Brother, from the age of doublethink - greetings! - Winston Smith, 1984 pgpj3kgqk3aWS.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:58:48, Antoine Beaupré wrote: I see there was one email about ffmpeg on the mailing list about a month ago, without any response, but that's all... I was talking about the deprecated debian-multimedia, my bad. A. -- The Net treats censorship as damage and routes around it. - John Gilmore pgpSGP9rBqp57.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On Mon, Feb 03, 2014 at 05:58:48PM -0500, Antoine Beaupré wrote: On 2014-02-03 17:25:40, Adrian Bunk wrote: ... Then maybe this RFP can focus on providing the ffmpeg binary again and not necessarily get into replacing libav altogether, which I think was the original intention here, hence my original email. :) No. Rogério is listing in the initial email in this RFP many reasons for the ffmpeg libraries. But he never mentions anything related to the ffmpeg commandline programs. He did mention he wanted to package ffmpeg as a replacement of libav, I stand corrected. Or are you seriously saying chromium would use the ffmpeg commandline programs? Now where did I ever mention chrome? You were claiming the original intention of this RFP was to provide the ffmpeg binary again. Since the original intention of this RFP that you were referring to listed chromium, that implies that you were saying that chromium would use the commandline tools. ... One of the proposals on the table is to bring back ffmpeg, at least as a program, possibly as a library. You seem to be saying that is insane, ... I would appreciate if you would in the future refrain from wrongly claiming that I said something, when I did in fact state the opposite: -- snip -- If all you expect to happen after apt-get install ffmpeg is that there is an ffmpeg binary that is using the ffmpeg libraries, then this might be doable. -- snip -- but I fail to see the technical reasons behind that argument, other than debian-multimedia vetoing it. Maybe that discussion should be taken there then? I see there was one email about ffmpeg on the mailing list about a month ago, without any response, but that's all... You do know the relevant history? What's your proposal to fix the problems with libav mentionned in this thread? What's your response to the claims that ffmpeg is a superset of libav and that libav is lagging in development? If ffmpeg is technically superior and compatible with libav, why shouldn't we package it? All I am saying is that suggestiong along the lines of having both the libav and ffmpeg libraries and then switching between them through apt-get install is insane. If you disagree with the Debian Multimedia Maintainers on which to use in jessie, the conflict resolution process is in the Debian Constitution. I feel there's a knee-jerk reaction against the inclusion of ffmpeg here, and I don't understand the technical reasons for that. Certainly we could offer ffmpeg as a replacement (Conflicts: Replaces:) of libav and people could choose between the two, especially if libav is such a drop-in replacement for packages that depend on ffmpeg... What part of the technical reason a binary/library compiled against a library cannot be used with a version of this library with a different soname don't you understand? I think any Debian Developper is perfectly entitled to work on a ffmpeg package, upload it to new and let the FTP masters decide what to do with it. Now of course to make other packages use its libraries is a matter that should be left to those other package's maintainers, that's a different story, and not the topic of this RFP, from what I understand. You already agreed that your claim The library names of ffmpeg and libav now seem perfectly orthogonal is not true. That is a mess, and would have to be sorted out by the Debian libav and ffmpeg maintainers before such an upload could happen. A. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- 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/20140203232134.gi26...@bunk.dyndns.info
Bug#729203: CTTE and reasonable solutions
On 04/02/14 12:08, Antoine Beaupré wrote: If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. As far as I understand it the problem is that it is *not* a drop-in replacement as far as the libraries are concerned, every package needs to be recompiled depending on which library should be used. So you would need two different packages for every program that uses the libraries if you wanted to offer both in parallel. And I don't think Adrian (or anyone else) is against ffmpeg as such, it's just that there should be made a decision which one to use in order to avoid these issues. Jan -- 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/52f024f9.2020...@majutsushi.net
Processed: #726545
Processing commands for cont...@bugs.debian.org: owner 726545 j.goe...@t-online.de Bug #726545 [wnpp] O: vimhelp-de -- Vi IMproved - Documentation files (German translation) Owner recorded as j.goe...@t-online.de. End of message, stopping processing here. Please contact me if you need assistance. -- 726545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726545 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.13914720225502.transcr...@bugs.debian.org
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 18:21:34, Adrian Bunk wrote: On Mon, Feb 03, 2014 at 05:58:48PM -0500, Antoine Beaupré wrote: On 2014-02-03 17:25:40, Adrian Bunk wrote: ... Since the original intention of this RFP that you were referring to listed chromium, that implies that you were saying that chromium would use the commandline tools. I obviously wasn't saying that. I also stated above I stand corrected, what else do you need here? One of the proposals on the table is to bring back ffmpeg, at least as a program, possibly as a library. You seem to be saying that is insane, ... I would appreciate if you would in the future refrain from wrongly claiming that I said something, when I did in fact state the opposite: -- snip -- If all you expect to happen after apt-get install ffmpeg is that there is an ffmpeg binary that is using the ffmpeg libraries, then this might be doable. -- snip -- I am refering to your position which you restate below but I fail to see the technical reasons behind that argument, other than debian-multimedia vetoing it. Maybe that discussion should be taken there then? I see there was one email about ffmpeg on the mailing list about a month ago, without any response, but that's all... You do know the relevant history? I am familiar with the fork, yes. However, things change and it seems that ffmpeg has picked up a lot of speed since the fork. Maybe it's time to reopen that discussion? Or maybe not, considering how this is going so far... What's your proposal to fix the problems with libav mentionned in this thread? What's your response to the claims that ffmpeg is a superset of libav and that libav is lagging in development? If ffmpeg is technically superior and compatible with libav, why shouldn't we package it? All I am saying is that suggestiong along the lines of having both the libav and ffmpeg libraries and then switching between them through apt-get install is insane. I do not see any answer to the technical questions I have asked above. I also do not see why this proposal is inherently insane. If you disagree with the Debian Multimedia Maintainers on which to use in jessie, the conflict resolution process is in the Debian Constitution. I am aware of the constitution as well, thanks. I wasn't aware I was in a conflict resolution process already, I was trying to get information about the situation. Things escalate quick around here don't they? :) I feel there's a knee-jerk reaction against the inclusion of ffmpeg here, and I don't understand the technical reasons for that. Certainly we could offer ffmpeg as a replacement (Conflicts: Replaces:) of libav and people could choose between the two, especially if libav is such a drop-in replacement for packages that depend on ffmpeg... What part of the technical reason a binary/library compiled against a library cannot be used with a version of this library with a different soname don't you understand? Well, that's one answer, thanks. I was under the understanding that ffmpeg was trying to keep backwards compatibility with libav, I guess that is all much clearer now. One thing I don't understand is how difficult this conversation feels for me right now. Maybe it's just me, but I was just looking at an offer to work on ffmpeg in Debian by a volunteer, and this is turning out to be a difficult conversation, what happened? I think any Debian Developper is perfectly entitled to work on a ffmpeg package, upload it to new and let the FTP masters decide what to do with it. Now of course to make other packages use its libraries is a matter that should be left to those other package's maintainers, that's a different story, and not the topic of this RFP, from what I understand. You already agreed that your claim The library names of ffmpeg and libav now seem perfectly orthogonal is not true. I fail to understand what that statement brings to the conversation. Does that make me a bad person? :P That is a mess, and would have to be sorted out by the Debian libav and ffmpeg maintainers before such an upload could happen. That would be great! I support such an initiative. I'm glad we agree. A. -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 pgp6qrHj4sewk.pgp Description: PGP signature
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:28 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Antoine Beaupré anar...@debian.org Cc: On Feb 3, 2014 3:12 PM, Antoine Beaupré anar...@debian.org wrote: On 2014-02-03 17:13:43, Rogério Brito wrote: Rogério, I would suggest you go ahead with the packaging and an upload, don't let the flames fan your enthousiasm. Thanks for the encouragement, Antoine. I am mostly paralized with this situation and I don't really know how to proceed. I think that the forces of having to potentially fight the tech-ctte, the pkg-multimedia-team, the ftp-masters and some other people is that is preventing me right now from packaging ffmpeg all by myself. I am not sure you should fight anyone here. Do the package, may it policy-clean and it will pass NEW. If someone wants to bring up something with the ctte, they can do it, but you don't have to right now. Having a discussion on pkg-multimedia may be necessary if other package dependencies should be changed, and it is probably good practice to discuss this topic on that mailing list, but it seems to me that people shouldn't object to the inclusion of another package in debian solely on the ground that they do not like it. If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. Mostly, but even with FFmpeg's attempt, not entirely IIRC. I tried to use abi-compliance-checker once, but failed, and i didnt have much time to delve into how to use it. Also Debian's very own ABI checking program icheck has some bugs, ironically, on testing FFmpeg http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427461. We have a policy for such procedures. Our social contract also says we should respond to the needs of users, and the overwhelming majority of people on this issue have voiced their need for a working ffmpeg implementation in Debian. We should respond to that. Exactly. [...] Timothy
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:56 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Jan Larres j...@majutsushi.net Cc: On Feb 3, 2014 3:39 PM, Jan Larres j...@majutsushi.net wrote: On 04/02/14 12:08, Antoine Beaupré wrote: If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. As far as I understand it the problem is that it is *not* a drop-in replacement as far as the libraries are concerned, every package needs to be recompiled depending on which library should be used. So you would need two different packages for every program that uses the libraries if you wanted to offer both in parallel. And I don't think Adrian (or anyone else) is against ffmpeg as such, it's just that there should be made a decision which one to use in order to avoid these issues. It's not as bad as you think. FFmpeg has a --enable-libav-incompatible-abi configure option. Didn't test the effectiveness of it though. Timothy Jan -- To unsubscribe, send mail to 729203-unsubscr...@bugs.debian.org.
Bug#729203: Fwd: Re: Bug#729203: CTTE and reasonable solutions
Sorry, forgot to CC bug tracker... -- Forwarded message -- From: Timothy Gu timothyg...@gmail.com Date: Feb 3, 2014 3:32 PM Subject: Re: Bug#729203: CTTE and reasonable solutions To: Adrian Bunk b...@stusta.de Cc: On Feb 3, 2014 3:24 PM, Adrian Bunk b...@stusta.de wrote: That is a mess, and would have to be sorted out by the Debian libav and ffmpeg maintainers before such an upload could happen. Agreed. But not exactly sure whether pkg-multimedia would want to collaborate... Timothy
Bug#737585: O: semanticscuttle -- Self-hosted and web-based social bookmark manager
Package: wnpp Severity: normal I intend to orphan the semanticscuttle package. The package description is: SemanticScuttle is a social bookmarking tool experimenting with new features like structured tags and collaborative descriptions of tags. Originally a fork of Scuttle, it has overtaken its ancestor in stability, features and usability. . * LDAP/Active Directory authentication * RSS feed support: global feed, user feeds, per-tag feeds, private feeds * Public and private bookmarks * Delicious and Browser bookmark import * Theming support * Firefox plugin I am not really using the Debian package for deployment anymore, and can therefore not really fix the release-critical bugs which affect the installs (#659390). I will probably switch to Zotero to manage my bookmarks anyways (#709925). If anyone wants to take over the package, I can provide some overview of the package, but, quite frankly, it's been so long since I touched it that I barely remember anything at all. ;) I'll try to update to the latest upstream at least. Sorry for the inconvenience. -- 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/20140204023157.26565.62837.report...@marcos.anarc.at
Bug#737587: RFP: commander-genius -- Commander Genius is a software piece that interprets the Commander Keen Invasion of the Vorticons and Galaxy series.
Package: wnpp Severity: wishlist * Package name: commander-genius Version : 1.6.5.5 Upstream Author : Gerhard Wolfgang Stein gerstr...@gmail.com * URL : http://clonekeenplus.sourceforge.net/ * License : GPL Programming Lang: C++ Description : Commander Genius is a software piece that interprets the Commander Keen Invasion of the Vorticons and Galaxy series. This is an interpreter for the well known Commander Keen games. -- 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/20140204025623.25576.38679.report...@heisenberg.scientia.net
Processed: O: vimhelp-de -- Vi IMproved - Documentation files (German translation)
Processing commands for cont...@bugs.debian.org: noowner 726545 Bug #726545 [wnpp] O: vimhelp-de -- Vi IMproved - Documentation files (German translation) Removed annotation that Bug was owned by j.goe...@t-online.de. stop Stopping processing here. Please contact me if you need assistance. -- 726545: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726545 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.139148789727719.transcr...@bugs.debian.org
Bug#737599: TAG: yad -- yet another dialog
Package: wnpp Severity: RFP URL: http://code.google.com/p/yad/ Copyright: Victor Ananjevsky anana...@gmail.com License: GNU GPL v3 This fork of zenity has been greatly improved since the fork. It is stable and mature. There are Debian packages at http://slavino.sk/ulozisko-apt. I have no idea of their quality having always compiled from source (I maintain the yad package for http://slackbuilds.org). I have no relationship with Victor Ananjevsky apart from being a happy user of yad. Best Charles -- 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/52f086f8.8080...@charlesmatkinson.org
Processed (with 1 errors): retitle 630422 to ITP: pwsafe -- pwsafe is a *nix command-line program
Processing commands for cont...@bugs.debian.org: retitle 630422 ITP: pwsafe -- pwsafe is a *nix command-line program Bug #630422 [wnpp] RFP: pwsafe -- pwsafe is a *nix command-line program Changed Bug title to 'ITP: pwsafe -- pwsafe is a *nix command-line program' from 'RFP: pwsafe -- pwsafe is a *nix command-line program' owner ! Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. -- 630422: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630422 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.139149776517254.transcr...@bugs.debian.org
Processed: owner 630422
Processing commands for cont...@bugs.debian.org: owner 630422 ! Bug #630422 [wnpp] ITP: pwsafe -- pwsafe is a *nix command-line program Owner recorded as Bill Blough de...@blough.us. thanks Stopping processing here. Please contact me if you need assistance. -- 630422: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630422 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.139149852021522.transcr...@bugs.debian.org
