Re: adduser/deluser on postinst
On Fri, Aug 03, 2007, Vincent Bernat wrote: > gdm Fixed in SVN; thanks. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435823: ITP: volpack -- fast volume rendering library
Package: wnpp Severity: wishlist Owner: Andreas Tille <[EMAIL PROTECTED]> * Package name: volpack Version : 1.0b3 Upstream Author : Philippe Lacroute <[EMAIL PROTECTED]> * URL : http://graphics.stanford.edu/software/volpack/ * License : free (see below) Programming Lang: C Description : fast volume rendering library VolPack is a software library for fast, high-quality volume rendering with this features: * Renders data sampled on a regular, three-dimensional grid. * Supports user-specified transfer functions for both opacity and color. * Provides a shading model with directional light sources, multiple material types with different reflective properties, depth cueing, and shadows. * Produces color (24 bits/pixel) or grayscale (8 bits/pixel) renderings, with or without an alpha channel. * Supports arbitrary affine view transformations. * Supports a flexible data format that allows an arbitrary C structure to be associated with each voxel. License: VolPack is covered by the following copyright notice: Copyright (c) 1994 The Board of Trustees of The Leland Stanford Junior University. All rights reserved. Permission to use, copy, modify and distribute this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice and this permission notice appear in all copies of this software and that you do not sell the software. Commercial licensing is available by contacting the author. THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Thanks to Michael Hanke <[EMAIL PROTECTED]> some packaging work was started. I'm currently changing his work to enabling statically and dynamically linked libraries. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (501, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.17-1-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435842: O: anthy -- A Japanese input method (backend, dictionary and utility)
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I intend to orphan the anthy package. Because I cannot take enough time to catching up anthy's release and because no one take over or become a co-maintainer of this package in [EMAIL PROTECTED] and [EMAIL PROTECTED] The package description is: Anthy is a Japanese input method working on X11 and emacs. It converts Hiragana text to Kana Kanji mixed text. It is implemented as a library and stores user's private information into their own home directory. Thus, Anthy is simple and secure (your information is protected from spoofing and snooping). Regards, Masahito Omote([EMAIL PROTECTED]) - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGs0W34QYOB7JaXPERAgWbAJ49/9wYOOMxS+GJoMr/1R2qgBiWNwCfdj7X 7yGdryiVnH+5So2Vy9DJ4oo= =OTrB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435838: ITP: cpm -- Console Password Manager
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: cpm Version : 0.22beta Upstream Author : Harry Brueckner * URL : http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm * License : GPL Programming Lang: C Description : Console Password Manager This program is a ncurses based console tool to manage passwords and store them public key encrypted in a file - even for more than one person. The encryption is handled via GnuPG so the programs data can be accessed via gpg as well, in case you want to have a look inside. The data is stored as as zlib compressed XML so it's even possible to reuse the data for some other purpose. . The software uses CDK (ncurses) to handle the user interface, libxml2 to store the information, the zlib library to compress the data and the library GpgMe to encrypt and decrypt the data securely. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (99, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-k7 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435847: ITP: pydoctor -- Python API document generator
Package: wnpp Severity: wishlist Owner: Guido Guenther <[EMAIL PROTECTED]> * Package name: pydoctor Version : 2 Upstream Author : Michael Hudson <[EMAIL PROTECTED]> * URL : http://codespeak.net/svn/user/mwh/pydoctor/ * License : custom Programming Lang: Python Description : Python API document generator Pydoctor is a tool for generating API documentation for Python modules based on their docstrings via static analysis. . It was written primarily to replace epydoc for the purposes of the Twisted project as epydoc has difficulties with zope.interface. License: All Rights Reserved Permission to use, copy, modify, and distribute this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Git repository is currently here: https://honk.sigxcpu.org/git/debian-packages/pydoctor.git/ but it will move to git.debian.org. Several projects including twisted, calendarserver and kiwi use it for generating their API documentation. Cheers, -- Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh diversions
On Fri, Aug 03, 2007 at 01:15:38PM +1000, Anthony Towns wrote: > On Wed, Aug 01, 2007 at 10:13:38PM -0700, Steve Langasek wrote: > > On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote: > > > diversions are far from being atomic. > > True, but it is persistent across upgrades and doesn't require any > > particular support from the package. > > Is it a bug (or a missing feature) that diversions aren't atomic? > > The --rename option to dpkg-divert means it can be done atomically if > dpkg-divert is clever enough, at least in all the ways that count. what is not atomic is that dpkg-divert will rename /bin/sh as /bin/sh.real or whatever, and then the postinst will recreate the symlink. Between those operations, you live without /bin/sh. dpkg-divert could make that atomicaly if it had an option --replace-with which would take the name of the file to divert _and_ the file to replace it with. That way, the diversion can be made with always a /bin/sh, if dpkg-divert does that: ln /bin/sh /bin/sh.distrib mv /bin/dash.temporary /bin/sh having /bin/dash.temporary created before the call to dpkg-divert. Sadly, afaict, there is no such option in dpkg-divert yet. Of course this would impose that all the arguments live in the same directory (as they must be on the same device). OTOH I'm not sure it's worth the hassle. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp3gElhtus4w.pgp Description: PGP signature
Re: needs=vc as menu field useful and needed?
On Thu, Aug 02, 2007, Nico Golde wrote: > > A lintian test for needs=vc programs that are not linked with svgalib > > or directfb would be nice. > > Oh that is a good idea. I will file a wishlist bug. Note that there are also framebuffer-only programs that directly use the /dev/fbX device. At least fbi (which is not in your list and would probably need needs=vc) and dvifb do so. -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435814: ITP: dictconv -- Dictconv convert a dictionay file type in another dictionary file type.
Package: wnpp Severity: wishlist Owner: Francesco Namuri <[EMAIL PROTECTED]> Package name: dictconv Version : 0.2 Upstream Author : Raul Fernandes <[EMAIL PROTECTED]> URL : http://ktranslator.sourceforge.net/ License : GPL Programming Lang: C++ Description : Dictconv convert a dictionay file type in another dictionary file type. Currently, it supports converting from Babylon glossaries, Freedict dictionaries, Sdictionary dictionaries and Stardict dictionaries to DICT dictionaries, plain text dictionaries and StarDict dictionaries. More file types will be added in new versions. . Homepage: http://ktranslator.sourceforge.net/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (850, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc5-custom.1 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
Thanks for the response.
>
> Hmm, I would question whether this is something we'd want to include in the
> Debian archive as-is; I think we already have way too many gcc packages
> being carried around with our releases and that we need to try to make this
> number go down, not add more copies of the gcc source code to the archive.
>
Unfortunately including the GCC source is very difficult to avoid for
this package. I have had thoughts about trying to use GCC GEM (Which is
not in debian from what i can see) to implement the data analysis and
export as a "GCC Plugin", however that is a large undertaking and I am
not sure that GEM is well maintained. It would also require a special
GEM patched GCC to be installed as another package anyway.
Before undertaking the process of building the packages in a policy
conforming way, is it possible to know if there is much likelihood of
the packages being included in Debian?
>> The idea is that this patched GCC/Doxygen should be installed
>> "alongside" existing GCC/Doxygen versions and should not interfere with
>> them.
>
>> Does anyone have suggestions as to how best I can tackle this problem in
>> a way that would be considered acceptable for inclusion in debian? The
>> current method works fine, but does not meet the debian policy requirements.
>
> I would recommend that you look into the Debian diff for the gcc-4.1 source
> package, to see how putting the version number into the binary name is
> handled ("gcc-4.1", "cpp-4.1", ...). The same could be done for edoc, which
> would be policy-compliant.
>
Thanks for the tip. Would it be fine to use a format similar to that
used by cross compiler packages? E.g: "edoc-g++" This would also include
a directory /usr/edoc A similar package for comparison would be: mingw32
The mingw32 package installs i586-mingw32msvc-g++ ... and also has a
directory: /usr/i586-mingw32msvc/bin ...
Would this be considered suitable? If so is there any reason why some of
the i586-mingw32msvc-* binaries for the mingw32 package have hardlinks
into the /usr/i586-mingw32msvc/bin/ directory and others do not?
I would prefer to have hardlinks for all the binaries prefixed with
edoc-* if i were to format my package like this. Since it should be
possible for a user to set PATH and LD_LIBRARY_PATH correctly and build
from the /usr/edoc/bin/ directories without requiring build tool prefixes.
> Since gcc-4.0 itself is no longer part of Debian (except for libgcc2 on
> hppa), you might even use the same naming scheme and have your package
> Conflicts/Replaces/Provides gcc-4.0, cpp-4.0, g++-4.0, and anything else
> needed.
The difficulty is that it is not really the same as GCC 4.0. It behaves
a little differently, uses much more memory and takes longer to compile.
I would not wish users to use the EDoc++ modified GCC without explicitly
knowing that they are doing so.
Thanks for the comments. I appreciate the help as this is my first
experience working with debian packages.
Brendon.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Final call for votes for "GR: Endorse the concept of Debian Maintainers"
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 211227d8-5b0a-4ff4-8837-915d24867d33 > [ 1 ] Choice 1: Endorse the concept of Debian Maintainers > [ 2 ] Choice 2: Further discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC signature.asc Description: Digital signature
Re: Packaging a difficult project
* Steve Langasek: > Hmm, I would question whether this is something we'd want to include in the > Debian archive as-is; I think we already have way too many gcc packages > being carried around with our releases and that we need to try to make this > number go down, not add more copies of the gcc source code to the archive. I believe that edoc doesn't use the code generator, only the front end, so it doesn't need care from port maintainers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh diversions
On Wed, Aug 01, 2007 at 10:13:38PM -0700, Steve Langasek wrote: > On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote: > > diversions are far from being atomic. > True, but it is persistent across upgrades and doesn't require any > particular support from the package. Is it a bug (or a missing feature) that diversions aren't atomic? The --rename option to dpkg-divert means it can be done atomically if dpkg-divert is clever enough, at least in all the ways that count. Cheers, aj, surprised it's not already atomic signature.asc Description: Digital signature
Re: /bin/sh diversions
On Fri, Aug 03, 2007 at 06:24:52PM +0200, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > On Fri, Aug 03, 2007 at 01:15:38PM +1000, Anthony Towns wrote: > > On Wed, Aug 01, 2007 at 10:13:38PM -0700, Steve Langasek wrote: > > > On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote: > > > > diversions are far from being atomic. > > > True, but it is persistent across upgrades and doesn't require any > > > particular support from the package. > > > > Is it a bug (or a missing feature) that diversions aren't atomic? > > > > The --rename option to dpkg-divert means it can be done atomically if > > dpkg-divert is clever enough, at least in all the ways that count. > > what is not atomic is that dpkg-divert will rename /bin/sh as > /bin/sh.real or whatever, and then the postinst will recreate the > symlink. Between those operations, you live without /bin/sh. > > dpkg-divert could make that atomicaly if it had an option > --replace-with which would take the name of the file to divert _and_ the > file to replace it with. > > That way, the diversion can be made with always a /bin/sh, if > dpkg-divert does that: > > ln /bin/sh /bin/sh.distrib > mv /bin/dash.temporary /bin/sh > > having /bin/dash.temporary created before the call to dpkg-divert. > Sadly, afaict, there is no such option in dpkg-divert yet. > > Of course this would impose that all the arguments live in the same > directory (as they must be on the same device). > > OTOH I'm not sure it's worth the hassle. Wasn't there a discussion a few weeks ago about having diversions be handled by dpkg directly, through a diversions file in the package control.tar.gz ? Or was it alternatives ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh diversions
On Fri, Aug 03, 2007 at 01:15:38PM +1000, Anthony Towns wrote: > On Wed, Aug 01, 2007 at 10:13:38PM -0700, Steve Langasek wrote: > > On Thu, Aug 02, 2007 at 06:54:49AM +0200, Mike Hommey wrote: > > > diversions are far from being atomic. > > True, but it is persistent across upgrades and doesn't require any > > particular support from the package. > Is it a bug (or a missing feature) that diversions aren't atomic? Maybe, but I'm not sure it can be fixed without the declarative diversions that were mentioned on the list a bit back? > The --rename option to dpkg-divert means it can be done atomically if > dpkg-divert is clever enough, at least in all the ways that count. This only lets you move /bin/sh to /bin/sh.frisbee as an atomic operation. It doesn't let you create the new /bin/sh at the same time, that only happens when the package is unpacked, which happens much later than the preinst. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
"Julien BLACHE" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Raphael Hertzog <[EMAIL PROTECTED]> wrote: I've read that but I didn't take it into account because people google for docs and they will find documentation recommending apt-get (they usually won't notice if the doc is recent or not). Furthermore, there's also the fact that on user forums there are people who will still be recommending apt-get as it's what they are using. So you might be right on your first assertion, but I don't agree with your conclusion "If doc is the only problem, then it's not a problem". When aptitude came out, we've been told that aptitude was the real apt frontend that apt-get was never meant to be to begin with (apt-get being only a debug/devel tool for libapt) and that it was the tool to use from now on for everybody except maybe for advanced users who will probably stick with apt-get. Either this hasn't got enough publicity, or people decided to stick with apt-get because aptitude didn't cut it. The former case is easy enough to fix before October 1st; the latter might not be that easy to fix, depending on the reasons behind the dislike for aptitude. Now, from the Debian users I know around me, I can tell you that none of them like aptitude, and they especially dislike the "install recommends by default" so-called "feature". I am a Debian user in so far as I maintain 0 packages for Debian, and am not a DD. I use aptitude almost exclusively. I install reccomends by default. I rarely have any reason to override that default. Things just work. I chose to use Aptitude because it worked and the dependency tracking feature was quite nice. (I'll admit that at the time, if you wanted an interactive package selector, your choices wre dselect, and aptitude. IIRC synaptic was not really in great shape at that time, and as you will learn form the rest of this message, would not have been appropriate even if it was in good working order.) Besides I accepted that apt-get was really only ever a minimalistic front-end for the APT package management system. Aptitude is much fuller featured. Some things to note about me though: I have been using Linux for only ~3 years, and even on day one I was a poweruser. I did not have any UNIX experience, but I had DOS experience, so the command line did not scare me. I decided not to fear things breaking as that is merely an opertunaty to learn how to fix it. So besides a bit a playing with Knoppix, and tomsrtbt, I installed a virtual machine containning a command line only Debian sid. That is what I still use. Yes, I dove right in to sid and never looked back despite having only ~1-2 months of linux experience (and of that, most was only part-time experience). I don't worry about breakage as it is not my production machine, and is command line only, so a good chunk of the breakage misses me completely. My main OS is still Windows (unfortuantely), so I learned some commands and whatnot that way. (I do intend to eventually swap, and run a Linux system on the hardware (with a desktop environment), and Windows in a VM, but have not yet done so.) As for why I chose Debian I honestlly don't rember. I belive it was because of hearing about the nice package management system. (Also, I had previously tried installing RedHat Linux on the metal of that laptop, and the results were awful. Problems with the video settings (X configuration issue I suspect), and an unsupported southbridge.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
On Fri, Aug 03, 2007 at 03:35:14PM +0200, Florian Weimer wrote: > > Hmm, I would question whether this is something we'd want to include in the > > Debian archive as-is; I think we already have way too many gcc packages > > being carried around with our releases and that we need to try to make this > > number go down, not add more copies of the gcc source code to the archive. > I believe that edoc doesn't use the code generator, only the front > end, so it doesn't need care from port maintainers. Which was not my objection. I understand and accept that edoc might not be a very good compiler to use on all architectures, and don't think that should be a reason to keep it out of the archive; my concern is that, depending on which binary packages it needs to build, edoc could take up as much as 1GB of space on our full mirrors, for something that should effectively be a patch against gcc. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435879: ITP: yum-metadata-parser -- A fast metadata parser for YUM
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" <[EMAIL PROTECTED]> * Package name: yum-metadata-parser Version : 1.1.1 Upstream Author : James Bowes <[EMAIL PROTECTED]> Florian Festi <[EMAIL PROTECTED]> Tambet Ingo <[EMAIL PROTECTED]> Jeremy Katz <[EMAIL PROTECTED]> Paul Nasrat <[EMAIL PROTECTED]> Seth Vidal <[EMAIL PROTECTED]> Terje Rosten <[EMAIL PROTECTED]> * URL : http://linux.duke.edu/projects/yum/ * License : GPLv2 Programming Lang: C, Python Description : A fast metadata parser for YUM C-based metadata parser python module to quickly parse XML metadata from YUM repository (RPMs) into sqlite databases. . Homepage: http://linux.duke.edu/projects/yum/ This python module is required to use newer createrepo (metadatas generators for RPM repository) releases. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (400, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash
Bug#435881: ITP: atheme -- Portable Modular IRC Services
Package: wnpp Severity: wishlist Owner: Bradley Smith <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: atheme Version : 2.2.0 Upstream Authors: nenolod <[EMAIL PROTECTED]> gxti <[EMAIL PROTECTED]> jilles <[EMAIL PROTECTED]> * URL : http://www.atheme.net/ * License : BSD Programming Lang: C Description : Portable Modular IRC Services This package is a portable, secure set of open source, modular IRC services, designed to run on many IRCds. Unlike alternative packages, Atheme's core is minimalistic, providing only core functionality. Atheme is a complete services set, excluding features designed for oper abuse. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGs6dkj3BimscY00cRAk6pAKCSJD7e5pvXLRHe8VrW+bPgRbU5rgCdE5wa ZIMks2u7RtRIotgkuxJH0gQ= =zG2F -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Package: wnpp Severity: wishlist Owner: Michael Biebl <[EMAIL PROTECTED]> * Package name: rsyslog Version : 1.18.0 Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]> * URL : http://www.rsyslog.com * License : GPL v2 or later Programming Lang: C Description : enhanced multi-threaded syslogd Rsyslog is an enhanced multi-threaded syslogd supporting, amongst others: * MySQL * syslog/tcp * RFC 3195 * permitted sender lists * filtering on any message part * fine grained output format control * backup log destinations . It is quite compatible to stock sysklogd and can be used as a drop-in replacement. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
> >> I believe that edoc doesn't use the code generator, only the front >> end, so it doesn't need care from port maintainers. > The GCC modification attempts to change as little in the GCC framework as possible and just performs analysis on the data structures generated by GCC as it compiles code. As such GCC still generates binaries. In fact one of the data output formats (Which I assume will be the most commonly used output format) for EDoc++ is to embed the EDoc++ specific data into the binary files generated by GCC in an .edoc section in the binary file (Which is later accessed using libbfd). This makes locating data for post processing a much easier task. As such the EDoc++ patched GCC still generates binaries and so it does not just include the front end. However I have made it plain that to use the resulting binaries is done so at the users risk as I can not guarantee the integrity of the resulting binary files, simply because I lack the man hours to do this. However with that said I have been using them myself and not encountered any problems. Also I am unable to maintain various system specific patches for GCC such as Debian, Fedora, NetBSD etc. Though I am not sure if these systems currently require platform specific patches from the existing GCC sources. > Which was not my objection. I understand and accept that edoc might not be > a very good compiler to use on all architectures, and don't think that > should be a reason to keep it out of the archive; my concern is that, > depending on which binary packages it needs to build, edoc could take up as > much as 1GB of space on our full mirrors, for something that should > effectively be a patch against gcc. > EDoc++ binaries are currently around 20M. It does not require any special binutils etc, but will just use what is already available for the system. I am currently building a single non-policy conformant .deb package. Brendon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sat, Aug 04, 2007 at 12:12:50AM +0200, Michael Biebl wrote: > * Package name: rsyslog > Version : 1.18.0 > Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]> > * URL : http://www.rsyslog.com > * License : GPL v2 or later > Programming Lang: C > Description : enhanced multi-threaded syslogd > > Rsyslog is an enhanced multi-threaded syslogd supporting, amongst > others: Why is rsyslog being multi-threaded interesting to our users? Isn't that an internal implementation decision? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435915: ITP: mira -- Whole Genome Shotgun and EST Sequence Assembler
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: mira Version : 2.8.2 Upstream Author : Bastien Chevreux URL : http://chevreux.org/projects_mira.html License : GPL Programming Lang: C Description : Whole Genome Shotgun and EST Sequence Assembler The mira genome fragment assembler is a specialised assembler for sequencing projects classified as 'hard' due to high number of similar repeats. For expressed sequence tags (ESTs) transcripts, miraEST is specialised on reconstructing pristine mRNA transcripts while detecting and classifying single nucleotide polymorphisms (SNP) occuring in different variations thereof. . The assembler is routinely used for such various tasks as mutation detection in different cell types, similarity analysis of transcripts between organisms, and pristine assembly of sequences from various sources for oligo design in clinical microarray experiments. . Homepage: http://chevreux.org/projects_mira.html Mira has been freed under the GPL last friday, I will try to package it quickly to help it having a good start. -- Charles Plessy Wako, Saitama, Japan Debian-Med packaging team. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
On Sat, Aug 04, 2007 at 02:18:29PM +1000, Hamish Moffatt wrote: > On Sat, Aug 04, 2007 at 12:12:50AM +0200, Michael Biebl wrote: > > * Package name: rsyslog > > Version : 1.18.0 > > Upstream Author : Rainer Gerhards <[EMAIL PROTECTED]> > > * URL : http://www.rsyslog.com > > * License : GPL v2 or later > > Programming Lang: C > > Description : enhanced multi-threaded syslogd > > > > Rsyslog is an enhanced multi-threaded syslogd supporting, amongst > > others: > > Why is rsyslog being multi-threaded interesting to our users? > Isn't that an internal implementation decision? > As the "target" user for this sort of package is a sysadmin type, I would saw it is an important enough detail that it should be in the short description. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
