Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Hi Harlan, On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote: > It's been a while since we made the decision not to pull from upstream's > git; Toni, I'd be happy to work with you on seeing if it's doable now. I think I have a suitable package now, being as cheap as possible, but it's off your git tree, which I took from https://anonscm.debian.org/git/collab-maint/ansible.git I had to change some things, though: * retrofit the docsite directory * adjust debian/control * adjust debian/rules It's for 2.4.1, and it's lintian clean. My changes build both packages. How can I best upload this stuff without disrupting yours, and without creating an entirely new repository? TIA! Cheers, --Toni++
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
On Tue, Jan 03, 2017 at 09:14:59PM -0500, Harlan Lieberman-Berg wrote: > Toni Mueller <t...@debian.org> writes: > > I found them only on PyPI. Did you find them elsewhere? > > We get them from releases.ansible.com. Are the docs in the tarballs in > PyPi? Nope, there are only man pages. Cheers, --Toni++
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Hi! A happy new year, everyone! On Sat, Dec 31, 2016 at 01:07:44PM -0500, Harlan Lieberman-Berg wrote: > Unfortunately, we don't build ansible off of the git repository, but > rather from the released tarballs. I found them only on PyPI. Did you find them elsewhere? > It's been a while since we made the decision not to pull from upstream's > git; Toni, I'd be happy to work with you on seeing if it's doable now. Let's get the -doc package into stretch first if it's not too late already. Cheers, --Toni++
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Hi Evgeni, On Fri, Dec 30, 2016 at 10:44:50PM +0100, Evgeni Golov wrote: > On Fri, Dec 30, 2016 at 12:58:02AM +0100, Toni Mueller wrote: > > documentation. This package aims to supply the documentation in HTML > > form offline, so one should not need to go to the aoupstream website to > > read it. > > Which source is this built from? > Do you basically want a mirror of https://docs.ansible.com/ansible/ in > a Debian package? I am building from a git clone of the ansible repository, and, more specifically, from the tag v2.2.0.0-1. > > Yours truly frequently suffers under bad network conditions, which make > > reading the website infeasible or outright impossible, so I think the > > package is useful. > > If it is more than ansible-doc , then it certainly is. My network conditions vary greatly, but too frequently, they are not good enough to access anything on the Internet. Working on that, but still, having a local copy of everything is very desirable from my POV. > I just wonder whether it is sensible to built it from an own source, > and not from the ansible source itself. I found a very easy way to build everything from the ansible source, at least for this tag. Cheers, --Toni++
Bug#849703: ITP: ansible-doc -- Documentation for Ansible
Package: wnpp Severity: wishlist Owner: Toni Mueller <t...@debian.org> * Package name: ansible-doc Version : 2.2.0.0-1 Upstream Author : RedHat <i...@ansible.com> * URL : http://www.ansible.com/ * License : GPL-3 Programming Lang: HTML, JavaScript Description : Documentation for Ansible Currently, the Ansible package in Debian lacks proper offline documentation. This package aims to supply the documentation in HTML form offline, so one should not need to go to the aoupstream website to read it. Yours truly frequently suffers under bad network conditions, which make reading the website infeasible or outright impossible, so I think the package is useful. I hope I can collaborate with the maintainer of the ansible package to maintain this package.
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Thomas, On Sun, Jul 13, 2014 at 11:52:24AM +0800, Thomas Goirand wrote: On 07/12/2014 08:46 PM, Toni Mueller wrote: As libressl is currently under heavy development, it is imho not to be expected to have that stable ABI you are asking for. Well, I don't agree with this view. If LibreSSL pretends to be a replacement for OpenSSL, then they should care about being ABI compatible, but they are only partially compatible already. The one thing that appears to stick out is that libressl has *no* support for egd, and on purpose (ie, it will not come back). And the other is arc4random(). so we can easily switch from one implementation to the other. Just like for MariaDB / MySQL in fact (not sure if these are still ABI compatible though). If that's not the case, then it looses a lot of its purpose. As Kurt wrote, GNUTLS becomes a better alternative then. If your application does not use things which are deemed deprecated, then it should be quite compatible, but by ripping out tons of old stuff, they of course also break something, at some point. The whole API becomes smaller simply because of that (I don't think this will be offset by the added features in other areas, like adding better cipher suites). As for GnuTLS, all I read so far is that it requires a *lot* of work to make a single application which has been developed together with OpenSSL, compatible with GnuTLS, because apparently almost everything differs to the point that it is unfeasible or impossible to have a compatibility layer. That turns smaller adjustments in applications into developing entirely different interfaces for each application, while GnuTLS itself still lacks a lot of features. At the face of it, that sounds like it is at least an order of magnitude more work, but likely even much more than that. And add to that that GnuTLS apparently works incorrectly almost half of the time (which translates to a significant security *downgrade* in my eyes), there is a huge amount of work set for those who would really try to fix it (ignoring the row between the upstream author and the FSF aside for the moment). OTOH, one guy already switched his entire Linux system over, so far with no visible adverse effects. And then? This gives no clue if he had to rebuild everything that build-depended on OpenSSL... That I don't know, but I have posed this question to the guy who made that statement. I'll keep you posted. On 07/13/2014 01:15 AM, Russ Allbery wrote: If you start using both for different packages, then you end up with shared libraries conflicting over which libssl they want to use, and then bad things start happening. Exactly! I fully agree with you on this. I do not think that accidentically using one library when one wanted to use the other will be an issue. FWIW, I've been told that a separate libressl.so is in the making, and if so, binary incompatibility can be taken for granted. This reminds me issues I had with mod-log-sql linked to MySQL and php as well, and when they were built against different versions... BOOM! I certainly do *not* want this kind of things to happen in Debian. Therefore, I'd very much prefer if we used OpenSSL *or* LibreSSL, but not have the choice between the 2, otherwise, that's a recipe for disaster. Ummm... what was BOOM exactly, please? Because within a release, OpenSSL (letter) versions should all be compatible with each other. Please don't upload LibreSSL to Sid *ever*, unless we collectively decide that we are switching away from OpenSSL (and for which a discussion would have to start). Well... as I said, I'm first and foremost planning to get it into experimental, and then we can see what it really is, fix the packaging etc.pp., and evaluate the package along the way. And while I hold the OpenBSD developers in very high esteem, I am still a bit wary that the package might be not as secure as we wish it to be, and therefore guess that we want to evaluate the package thoroughly for some time before the discussion about switching over can even start in a reasonable manner. Having said that, I value all of your input, but feel not halfway as much trigger happy as some of you seem to think I am. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714184831.ga12...@spruce.wiehl.oeko.net
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Jeroen, On Sun, Jul 13, 2014 at 12:22:49PM +0200, Jeroen Dekkers wrote: At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote: Ok, but for whatever reason, they have an imho not as shiny track record, as has OpenBSD. Which is no wonder, given all the revelations we have had recently, but hey, sometimes one has to make a decision. OpenSSL was part of OpenBSD before they created the LibreSSL fork, so how isn't OpenSSL part of the OpenBSD track record? it is in the way that they include it, and it also contributed a significant amount of all patches that were required over the years, but the typical way OpenBSD operates - from my perspective - is, they include something (eg. Sendmail), and once they get fed up with it for whatever reason, unless they find something acceptable out there (eg. nginx instead of Apache, or nsd(?)+unbound instead of BIND), they start to roll their own. A few releases later, the old stuff is being demoted or removed entirely (eg. for RAIDframe - softraid, the switchover period where you could choose was more than four years, afair). Such changes do happen in a disruptive manner, as there is usually nothing that aids you in converting your setup from the old to the new software. It depends on how you look at it. If you see the OpenSSL API as something that isn't really well designed then other libraries not copying the API is actually a good thing. Yes and no, but if it is more than ten times the amount of work, it is likely never getting done, for the simple reason that everyone is lacking resources. You forget one of the big problems with OpenSSL that LibreSSL doesn't fix: the license. Granted. Due to the amount of inherited code, it can't. We'll see how things evolve as the amount of inherited code will dwindle. It actually makes the mess even bigger, given that some of the GPL exceptions only talk about the OpenSSL library and don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in for OpenSSL we can't replace OpenSSL with LibreSSL for those projects. Yes. Thanks for pointing this out. You also forget to list two other TLS libraries: * NSS, in my opinion the biggest downside of NSS is that it includes NSPR. This both increases the code size a lot and makes the API less nice if I remember correctly. Hmmm... yes. I was under the impression that not very many people were using it, but looking at my system, NSS + NSPR ~ 3,5MB, while libssl1.0.0 comes in at ~3MB. Add ~1MB for sqlite3 and zlib1g in the case of NSS... * PolarSSL, which I really like from a technical point of view. Featurewise it is pretty complete (the only major feature it doesn't implement is DTLS AFAICS), while being one tenth the size of OpenSSL / GnuTLS: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version that is used by the Dutch government. The downsides are that it looks like it doesn't have a stable API and contributing needs copyright assignment because it is dual-licensed. It still gets 5 out of 16 answers wrong, as per the comparison sheet included here: https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714200800.gb12...@spruce.wiehl.oeko.net
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Kurt, On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote: What are you doing with the binaries, include files, man pages, ...? Will they conflict with the ones from openssl? my intention is to package this stuff so one can have both openssl and libressl installed in parallel. libressl currently has libraries with these sonames: libssl.so.26 libcrypto.so.29 If you're interested in maintaining such a package, why did you never respond to the RFH for openssl? There are a number of reasons for that, but one has been that I was unhappy about the perceived 'closedness' of the project, and my general feeling that I would like to have an alternative to openssl, which has been festering for several years now. For a while, I was hoping for libgnutls, but after the wakeup call, sent by heartbeat, I tried to figuere out which would be the best way forward, and I generally trust the OpenBSD folks, who are the vast majority behind LibreSSL, much more with respect to their ability to understand security and pursuing a no backdoors philosophy than most other people. FWIW, I have well over a decade of very good experience with OpenBSD, although I prefer Debian for most purposes, including a general slant towards copyleft (GPL) instead of copyright (BSD). They simply provide one of the, or the one, most viable alternatives to OpenSSL, thus helping to break down the obviously unhealthy monopoly that currently is OpenSSL. @Marco et al: I'll answer your other questions RSN, but the first portable release has only appeared yesterday, so it'll take some time until the dust settles. And no, I don't think we should go into production and switch to LibreSSL right now. But we should definitely have it. @Kurt: That should imho go to devel@, not only to you and the BTS. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712115345.ga10...@spruce.wiehl.oeko.net
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi Kurt, [ I have trimmed the Cc list - we are all on devel@, anyway, right? ] On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote: On Sat, Jul 12, 2014 at 01:53:45PM +0200, Toni Mueller wrote: On Sat, Jul 12, 2014 at 01:25:47PM +0200, Kurt Roeckx wrote: What are you doing with the binaries, include files, man pages, ...? Will they conflict with the ones from openssl? my intention is to package this stuff so one can have both openssl and libressl installed in parallel. libressl currently has libraries with these sonames: libssl.so.26 libcrypto.so.29 I don't really like it, since it could potentionally clash with the ones provided by openssl. But it seems unlikely that openssl will ever use that as soname. I had the feeling openbsd didn't care much about ABI stability, and that being at 26 and 29 already doesn't give me a good feeling either. I hope you don't have to go and change the binary package names each time you upload a new version. Actually, these version numbers typically correspond with the version numbers in the rest of their system. As libressl is currently under heavy development, it is imho not to be expected to have that stable ABI you are asking for. OTOH, one guy already switched his entire Linux system over, so far with no visible adverse effects. I was never very happy with it either. But it has very recently changed, and I think it's going in the right direction. I'm now also in the openssl development team. Good. That does help to improve my trust with it. I'm not really sure what you mean by this. I'm pretty sure the openssl development team has a pretty good understanding of security and I don't see anybody adding a backdoor in it. Ok, but for whatever reason, they have an imho not as shiny track record, as has OpenBSD. Which is no wonder, given all the revelations we have had recently, but hey, sometimes one has to make a decision. FWIW, I have well over a decade of very good experience with OpenBSD Not everybody has the same experience with them. Yes. Not everybody has an intention to use LibreSSL, either, but regarding crypto, they usually know their stuff well above average. See eg. their OpenSSH, which has seen very widespread adoption. I think GnuTLS is actually a better alternative and wish there were more people developing and using it. But developing GnuTLS is a full-time job, and then there's the control problem with the FSF - you are certainly aware about the problems the original upstream ran into when he wanted to break loose from the FSF (for a reason I have forgotten). LibreSSL is a much lower-hanging fruit, as it is supposed to be mostly, or entirely, plug-compatible with OpenSSL. To me, the playing field largely looks like this atm: * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge amounts of work to make significant use of it. * MatrixSSL, which once had a dubious license, and which still did not come out too well in the SSL lib comparison I recently saw (see the list archive), * the now newly staffed OpenSSL project, with their mixed track record (eg. FIPS), and now * LibreSSL, which sounds much like an OpenSSL on a diet, and with some exercise, and promising thrust behind it, but mostly simply a drop-in. And I guess the BoringSSL people will chime in sooner or later, too... Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712124645.gb10...@spruce.wiehl.oeko.net
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi, On Sat, Jul 12, 2014 at 07:43:44AM +0200, Marco d'Itri wrote: On Jul 12, Toni Mueller supp...@oeko.net wrote: * Package name: libressl I am highly doubtful at best. in which respect, and why? What are your plans exactly? My plan is to first build the package(s) and upload to experimental, so people can start to play with it. Would it have the same SONAME of openssl and conflict+provide it? I would like to make it co-installable with OpenSSL, but in general, this should be a drop-in replacement until APIs really diverge in a visible way. Yes, it would provide 'openssl', but I intend to place them into a different directory, so you might have to use LD_PATH to get them. Whether it has to conflict with openssl, I'll figure out that later, if otherwise the case would arise that a binary might get libssl from one package, and libcrypto from the other. So far, it looks like a recompile could be necessary. But since the upstream package has seen the light of day only yesterday (see http://article.gmane.org/gmane.os.openbsd.announce/186 for the announcement), things are not yet stable. For the technical side of the discussion, you can read http://dir.gmane.org/gmane.os.openbsd.tech). Would it be a totally different library which packages would build-depend on? Packages currently build-depending on openssl should be able to build-depend on openssl-dev | libressl-dev. For recent versions of OpenSSH, it already works, and another user writes: Just switched my slackware 14.1 box over to libressl instead of openssl and it's working great so far, no problems at all. So I guess usability is already good. But imho, it does have to stand the test of time, and receive independent review, and much more exposure. Which is one reason why I think it is a very good idea to expose it to the Debian and related communities. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712130429.gc10...@spruce.wiehl.oeko.net
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Package: wnpp Severity: wishlist Owner: Toni Mueller t...@debian.org * Package name: libressl Version : 2.0.0 Upstream Author : The OpenBSD project, the OpenSSL project et al. * URL : http://www.libressl.org/ * License : BSD, OpenSSL, SSLeay, Public Domain. Programming Lang: C Description : SSL library, forked from OpenSSL LibreSSL strives to maintain API compatibility with OpenSSL, but do away with all the cruft. After a long series of OpenSSL problems, recently highlighted by the infamous Heartbleed bug, a group inside OpenBSD decided to fork OpenSSL and adapt the code to modern coding standards. Along the way, a lot of compatibility with older architectures and toolchains was discarded. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140711220627.24261.14073.report...@spruce.wiehl.oeko.net
Bug#726262: any progress on this front?
Hi, I wanted to use salt, but stumbled over this dependency issue. Unfortunately, the upstream bug has also seen no activity for half a year already, so I wonder how to make progress now. I mean, in the absence of a usable PyCrypto integration, and with M2Crypto gone, it very much looks like salt is becoming a no-go in Debian - right? Please enlighten me! Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140410100425.ga22...@spruce.wiehl.oeko.net
Bug#560244: ITP: mysql-cluster
Hi Tom, On Tue, 10.08.2010 at 10:09:47 -0400, debianbugs.b...@spamgourmet.com debianbugs.b...@spamgourmet.com wrote: Thanks for the update. I am really glad this being worked on. Do you know if the plan is have 2 separate packages like in Ubuntu, one w/ cluster support and one without (mysql-cluster-server mysql-server)? as there is already a non-cluster-enabled set of mysql packages, which are completely outside of my scope, there'll (hopefully) be only a set of cluster-enabled packages from my end, while, in theory, the other group continues to do their own and produce packages that are not cluster-enabled. Or maybe I join them at some time, and the packages get somehow unified. Who knows, but at this point, the focust should be to get the packages done in the first place. Also, if I can be of assistance in this effort to get this into Debian please let me know. As I said, all help is welcome. If you are somewhat familiar with the MySQL code base, and/or their clustering techniques, that would imho be a big plus. Kind regards, --Toni++ -- 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/20100810151636.18170.qm...@oak.oeko.net
Bug#560244: ITP: mysql-cluster
Hi, On Mon, 09.08.2010 at 11:31:30 -0400, debianbugs.b...@spamgourmet.com debianbugs.b...@spamgourmet.com wrote: Unfortunately the Ubuntu mysql-cluster package is broken, I'm aware of that with respect to Debian - simply recompiling the package does not work, or at least not for Lenny (that's where I needed it). since the release of 10.04, although there is a workaround that works. I didn't see that. The bug report for this issue has been open since May with no activity, it's status is still still listed as new: https://bugs.launchpad.net/ubuntu/+source/mysql-cluster-7.0/+bug/579732 I'm not overly concerned with Ubuntu bugs atm, although I'm willing to consider patches that make things work on Ubuntu if the Debian side is all green. I was really hoping that mysql-cluster would be available in Debian 6, but I not optimistic as there seems to be no activity, and squeeze is now frozen. Please take into account that I'm so far doing this single-handedly, while the non-cluster-enabled mysql package is maintained by a whole team. I'm more than willing to team up, but wasn't yet able to make all connections. Also, this package does not currently have the highest priority for me, but will, once finished, also be available as a backport. -- Kind regards, --Toni++ -- 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/20100809162629.13858.qm...@oak.oeko.net
Bug#560244: State of affairs wrt. mysql-cluster?
Hi, as I stated in BTS#585877, the mysql-cluster package is missing. I'd like to jump on any already-running packaging bandwaggon, as I need this package rather urgently. TIA! Kind regards, --Toni++ -- 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/20100614171910.15093.qm...@oak.oeko.net
Bug#577270: ETA?
Hi, I'm looking forward to your package, and really not only want to use it myself, but see it in Squeeze, too. Can you please tell me when the package will be ready? TIA! Kind regards, --Toni++ -- 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/20100508114154.12662.qm...@oak.oeko.net
Bug#577270: ETA?
Hi Nikolai, On Sat, 08.05.2010 at 22:49:15 +1000, Nikolai Lusan niko...@lusan.id.au wrote: sponsor to have it uploaded to the archives. My problematic health means I am not able to devote the time I would like to this, I am hoping to have these last few things done in the next fortnight. I hope you recover soonish. If you need help, please ask. Kind regards, --Toni++ -- 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/20100508131213.18080.qm...@oak.oeko.net
Bug#562200: ITP: fuzzyocr -- interface SpamAssassin to various OCR packages
On Sun, 14.03.2010 at 14:31:31 +0100, Philipp Kern pk...@debian.org wrote: On Wed, Dec 23, 2009 at 07:58:01PM +0100, Toni Mueller wrote: * Package name: fuzzyocr * URL : http://fuzzyocr.own-hero.net/ * License : Apache 2.0 Programming Lang: Perl Description : Interface SpamAssassin to various OCR packages That's already in Debian as source package fuzzyocr. Still I doubt its usefulness today because there's not that much picture spam left anymore, isn't it? Thanks for pointing the presence of the package out to me. As for the usefulness, I think that it can't hurt much, but I'd rather not let down my guards and then be hit by a new wave of an old spamming technique. My personal impression is that spammers cycle through an ever-increasing arsenal of methods to slip their spam by user's filters. I don't have statistical evidence to back up this statement, however. -- Kind regards, --Toni++ -- 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/20100325152012.5395.qm...@oak.oeko.net
Bug#572883: RFP: jmemorize -- flash card program to aid learning foreign languages
Package: wnpp Severity: wishlist * Package name: jmemorize Version : 1.3.0 Upstream Author : Riad Djemili em...@riad.de * URL : http://jmemorize.org * License : GPL Programming Lang: Java Swing Description : flash card program to aid learning foreign languages jMemorize is written in Java and uses Leitner flashcards to make memorizing facts not only more efficient but also more fun. jMemorize manages your learn progress and features categories, Unicode flashcard texts, statistics and an intuitive interface. -- 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/20100307115838.12524.89499.report...@spruce.test.oeko.net
Bug#534910: any progress?
Hi, I'm looking into this package as well. Is there any progress on it? Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562200: ITP: fuzzyocr -- interface SpamAssassin to various OCR packages
Package: wnpp Owner: Toni Mueller t...@debian.org Severity: wishlist * Package name: fuzzyocr Version : 3.6.0 Upstream Author : Christian Holler and Jorge Valdes * URL : http://fuzzyocr.own-hero.net/ * License : Apache 2.0 Programming Lang: Perl Description : Interface SpamAssassin to various OCR packages Taken from their website: FuzzyOcr is a plugin for SpamAssassin which is aimed at unsolicited bulk mail (also known as Spam) containing images as the main content carrier. Using different methods, it analyzes the content and properties of images to distinguish between normal mails (Ham) and spam mails. The methods mainly are: * Optical Character Recognition using different engines and settings * Fuzzy word matching algorithm applied to OCR results * Image hashing system to learn unique properties of known spam * images * Dimension, size and integrity checking of images * Content-Type verification for the containing email In short, it's imho an important add-on to SpamAssassin these days. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'proposed-updates'), (450, 'testing'), (250, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475517: ITP: python-webunit -- Unit test websites by simulating a web browser
Package: wnpp Severity: normal Owner: Toni Mueller [EMAIL PROTECTED] * Package name: python-webunit Version : 1.3.8 Upstream Author : Richard Jones [EMAIL PROTECTED] * URL : http://www.mechanicalcat.net/tech/webunit/ * License : MIT Programming Lang: Python Description : Unit test websites by simulating a web browser Licence as per http://www.opensource.org/licenses/mit-license.php The package provides a unit testing library for writing programs to test websites. The library features things like automatically following redirects, filling and reposting forms etc.pp. The package is required by funkload to enable the re-play and test-run funcionality. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
Hi, On Fri, 21.12.2007 at 11:14:01 -0800, Russ Allbery [EMAIL PROTECTED] wrote: Is the version that is proposed to be packaged patched to reject mail at the SMTP level for unknown users rather than accept mail and bounce it later? qmail in its default operational mode is a spam reflector and hence broken by design, and shouldn't be accepted into Debian. However, perhaps this has been fixed by the community since djb's last release? I suggest packaging qmail-ldap (www.qmail-ldap.org) instead, which fixes this problem and adds a number of other desirable features as well (compressed mail transfer, TLS support, cluster support, you-name-it). Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
Hi, On Sun, 23.12.2007 at 20:17:16 +0100, Turbo Fredriksson [EMAIL PROTECTED] wrote: There are times where qmail-ldap is to much (on hosts where a smart host is used for example) and there I use the 'simple' qmail package. On mail servers, I use the qmail-ldap package... why, just set control/ldapsoftok, and you're all set (probably), except that you need the ldap libs being installed. It will be easier to maintain one source package instead of two... Right. How about integrating ldap-control, too? Preferably, the package should be taken over (if the current maintainer isn't interessted!!) by someone that understand both qmail and qmail-ldap. I'll be happy to help, but I don't have time to be the official maintainer - unless I get help that is. Same thing here. ;) Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Hi Sean, On Thu, 20.12.2007 at 09:09:37 +0100, sean finney [EMAIL PROTECTED] wrote: and i just have to add that i think it's really silly to add a package/program called tcpwatch that doesn't actually... watch tcp connections. but whatever, it's not like i'm installing it. well, that would be just following established tradition (and meet user's expectations) in keeping the name, but I'm currently considering to rename the program and fix the problem of users not easily finding it via README.Debian, while keeping the word 'tcpwatch' somewhere in the package name. The resultant program will then be placed in /usr/bin, under an appropriate name. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Hi, On Wed, 19.12.2007 at 18:23:19 -0200, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Well, personally, I'd rather not have such a thing in Debian with that name. And the fact that upstream called it that way doesn't speak highly of the tool, either IMHO. well, the latest release of that tool is dated 2004, and it was developed by a person who has no primary interest in network traffic analysis. Having said that, I have also to say that We have *real* tcp stream/flow watchers and recorders in Debian already. Also, ethereal/wireshark can postprocess and analyze http traffic, if you require a GUI. If this new tool can do better for http traffic (which I this is highly irrelevant for the matter at hand because this tool is specifically well suited to be used as a tool from inside funkload (not by humans directly these days) to record web requests and write them to file as Python code which you can later modify to automate web-related tasks, or run tests against web based applications. Rewriting funkload to do that with a different tool, eg. wireshark, is nigh impossible, or at least highly unreasonable, given that the tcpwatch script is 1485 lines of pure Python _only_, with no external dependencies. don't doubt it could, but it is not certain so far), it should at least be properly named... And if it cannot do better than the tools we already have in the archive, why package it? It enhances the functionality of funkload in a very good way many users of funkload actually use, and it fits into the funkload suite like a glove, so to say. It's more like a libary than a self-contained program except that it actually is, and still has its own Tkinter GUI, too (for those of us who like retro computing). Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Hi, On Thu, 20.12.2007 at 08:50:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: In that case, you could call the package funkload-tcpwatch? Perhaps even install the binaries in /usr/lib for use by funkload only? it is only one binary, and in fact, I already thought about that, but I'm a bit undecided yet because the program still can be used the other way, which I'm not going to change. Renaming the package is a good idea, but whether renaming the program itself is, I have to think over. For such programs, there exists /usr/libexec on some systems, but not in Linux as far as I know. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Hi, On Thu, 20.12.2007 at 00:06:55 +0100, sean finney [EMAIL PROTECTED] wrote: the FHS (and debian by extension) doesn't provide support for /usr/libexec. in every case i know of, contents of what would otherwise have gone in /usr/libexec go in /usr/lib/package/ instead. but this is a misconception because the program *can* be used individually, and it was also developed much earlier than whatever /usr/lib/package you might think is appropriate. And last but not least, you find eg. sendmail in /usr/libexec on BSDs, but not in /usr/lib/sendmail/sendmail on Linux, don't you? Anyway, I'll put the program where I think it fits, and it will be in accordance to packaging rules. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Package: wnpp Severity: wishlist Owner: Toni Mueller [EMAIL PROTECTED] * Package name: tcpwatch Version : 1.3 Upstream Author : Shane Hathaway [EMAIL PROTECTED] * URL : http://hathawaymix.org/Software/TCPWatch/ * License : ZPL 2.0 Programming Lang: Python Description : tcpwatch is a recorder for HTTP requests in Python tcpwatch is a HTTP traffic monitoring program and proxy in Python. This program allows recording of HTTP requests by being used as a proxy server. It writes out the requests sent to a file. This program is recommended by funkload, as it is required for funkload's recording option to work. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-amd64 Locale: LANG=de_DE.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: changed owner
owner 456782 ! thanks This one is to fix Lintian warnings. :| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
Hi, On Mon, 17.12.2007 at 23:10:35 +0100, Guus Sliepen [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 10:42:46PM +0100, Toni Mueller wrote: * Package name: tcpwatch Description : tcpwatch is a recorder for HTTP requests in Python A few things: why is it called tcpwatch when it only watches HTTP requests? A better name would be httpwatch. it's named that way by upstream. I want to keep confusion to a minimum and don't see much benefit in renaming it, esp. as it is called that way in all the literature. No need to make Debian different only because we can, imho. Iceweasel and friends cause sufficient confusion already (although this is a different case). The tag system is a better way to indicate that this program is written in Python. That may well be. I'll look into this. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351082: any progress?
Hello Jose, did you make any progress? I have an urgent need for this package, and am willing to create it. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377956: ITP: python-psycopgda2 -- PostgreSQL adapter for Python
Hello Hamish, On Thu, 13.07.2006 at 09:03:15 +1000, Hamish Moffatt [EMAIL PROTECTED] wrote: Wouldn't upstream intend to package it himself? Please contact him to check his plans. ok, I missed, and will check, that, but was deluded into thinking he wouldn't because he is also not the maintainer of the v1 package. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377956: ITP: python-psycopgda2 -- PostgreSQL adapter for Python
Package: wnpp Severity: wishlist Owner: Toni Mueller [EMAIL PROTECTED] Hello, I intend to package this module which would be a successor of python-psycopgda * Package name: python-psycopgda2 Version : 2.0.2 Upstream Author : Federico Di Gregorio [EMAIL PROTECTED] * URL : http://initd.org/pub/software/psycopg/ * License : GPL with OpenSSL and Pg exeption, ZPL and BSD for parts of the package Programming Lang: C, Python Description : PostgreSQL adapter for Python psycopg - Python-PostgreSQL Database Adapter psycopg is a PostgreSQL database adapter for the Python programming language. This is version 2, a complete rewrite of the original code to provide new-style classes for connection and cursor objects and other sweet candies. Like the original, psycopg 2 was written with the aim of being very small and fast, and stable as a rock. psycopg is different from the other database adapter because it was designed for heavily multi-threaded applications that create and destroy lots of cursors and make a conspicuous number of concurrent INSERTs or UPDATEs. psycopg 2 also provide full asycronous operations for the really brave programmer. psycopg is free software (free as in freedom but I like beer too.) Licensing information is available in the LICENSE file. Note: If there is already a package (which I failed to detect), please notify me. In that case, I'd like to avoid duplicating the effort. Best, --Toni++ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324557: ITA
retitle 324557 ITA - will make a stab at it owner 324557 [EMAIL PROTECTED] thanks pgpLhqzkdsI72.pgp Description: PGP signature
Bug#241444: ITP: pmacct -- promiscuous mode traffic accountant
Hi, On Thu, 01.04.2004 at 20:42:43 +1000, Jamie Wilkinson [EMAIL PROTECTED] wrote: * URL : http://www.ba.cnr.it/~paolo/pmacct/ pmacct is a tool designed to gather traffic information (bytes and number of packets) by listening on a promiscuous interface, which may facilitate billing, bandwidth management, traffic analysis, or creating usage graphs. you may want to look at net-acct, too: ii net-acct 0.71-5 Usermode IP accounting daemon which works very similar, judging from your cursory description. Best, --Toni++
