Bug#446665: mercury: should this package be removed?
Hi... On Feb 20, 2008 9:50 AM, Paul Bone <[EMAIL PROTECTED]> wrote: > Mercury also supports 'grades', this makes it different to other > compliers and more interesting to package. Each grade represents a > complier backend and some options. There are two C backends, a Java > backend, and Erlang backend and a MSIL backend. Options can include > optional garbage collection (as apposed to never reclaiming memory), > profiling support, debugging support and more. > > I'd like to package the library and runtime for each grade. These can > all be installed concurrently and won't conflict. There are at least two issues you may have to deal with here: * Mercury does not provide any guarantees about a stable library ABI, so you'll have difficulty packaging grades using shared libraries and not breaking applications when you update the libraries. * Mercury standard libraries can be very large (tens of megabytes in some of the debug grades), so packaging every possible grade seems rather wasteful of archive space. If you ask me, you need to pick a small set of useful grades which cover most use cases. I'm not sure how many architectures Debain supports at the moment, but if you aren't careful you could easily consume hundreds of megabytes of fileserver space just on Mercury library grades (10+ architectures * 10s of Mb/grade * many grades). Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351122: NMU
Hi... On Apr 22, 2006, at 9:19 AM, Torsten Marek wrote: Hi, I've NMU'ed your package to bring your package in shape for the upcoming Python transition. Thanks. Unfortunately I no longer have the time or inclination to work on my debian packages, so they're effectively abandoned by me. I'll orphan them when I get a chance. Cheers, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360654: libapache2-mod-python: mod_python 3.2.8 is now available, are you still packaging mod_python ... ?
Hi... Julien Cigar wrote: I wondered if you're still maintaining mod_python .. ? It hasn't been updated for a while and version 3.2.8 seems to fix some nasty bugs ! A python2.4 package would be appreciated too :) Not really. I'm too busy to touch it, and I don't think I'll have much more time any time soon. If you or someone else would like to adopt it they'd be very welcome to do so. Cheers, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#324847: Please package python2.4-ldap
Hi.. Please do an NMU whenever you like. You can take over as maintainer if you like, since I don't have time to maintain it properly. Cheers, Peter Matej Vela wrote: Hi, I really need python2.4-ldap at work, so unless you object I'll do an NMU in two weeks time. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348514: python-biggles 1.6.4-1.1 NMU
Hi... If you want to adopt it, I'd appreciate that. Cheers, Peter On Jan 28, 2006, at 12:03 PM, Matej Vela wrote: Hello, I'm doing an NMU of python-biggles to fix #326234, #331003, and #348514; diff attached. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338564: mercury: please build with system libgc
tags 338564 + wontfix thanks Brian M. Carlson wrote: Package: mercury Severity: important Please build mercury with the system libgc. It makes it harder on porters when they have to patch several different copies of code in several different packages. It also bloats the archive unnecessarily. Unfortunately mercury uses a modified libgc, so this isn't possible. (It's a logic programming language, so the garbage collector has to understand backtracking). =) Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298101: Included README is useless
Hi... On Fri, Mar 04, 2005 at 02:38:07PM -0300, Guilherme de S. Pastore wrote: > Package: libapache-mod-python > Version: 2:2.7.10-4 > Severity: minor > > Hi, > > the README file included in libapache-mod-python2.3 is absolutely > useless in the Debian package, since it only provides compilation > instructions =) You seem to assume that I read the README =) I take your point, and I'll remove it in the next upload. =) Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293585: python2.3-ldap: libldap >= 2.1 required but not specified
Hi... On Fri, Feb 04, 2005 at 04:19:10PM +0100, Herv? Cauwelier wrote: > Package: python2.3-ldap > Severity: normal > > Hi, I've found _ldap.so is importing symbols like ldap_passwd (and > ldap_first_reference?) that you can only find in libldap 2.1 and up. > > I suggest reinforcing the dependencies with a minimum version > requirement. I know this is unusual but I've found this "bug" while > trying to use python2.3-ldap backported on a Woody. Quite right. I'll fix it soon. =) Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289801: Logtail should output error messages to stderr, not stdout
Package: logtail Version: 1.2.33 Severity: normal Hi... Logtail should not output error messages to standard output, since this violates the principle of least surprise. In particular, my application was broken by the semantics of logtail changing in version 1.2.21 (when you added switches for the default arguments to logtail). I think this was a bad move -- you broke an interface used by other people for no immediately apparent reason. logtail is _not_ only used by logcheck! Please consider other users of logtail next time you change something. That notwithstanding, since logtail prints its error messages to standard output, the error message about the incorrect argument format is lost. One would expect the normal usage of logtail would have been something like: logtail logfile offsetfile | some_program With the new version of logtail, this produces an error message to standard output, which is then sent to 'some_program'. I would claim that the correct behaviour is to send the message to standard error, so logtail is not silently broken by installing logtail from sarge. =) Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
