Bug#544539: RFP: Linux Unified Kernel
Quoting "Patrick Matthäi" : Ivan Borzenkov schrieb: Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org --- Please fill out the fields below. --- Package name: Linux Unified Kernel Version: 0.2.4-1 Upstream Author: Insigma li...@insigma.com.cn URL: http://www.longene.org/en/ License: GPL Description: wine and windows drive model in kernel The LUK project aims to add all Windows kernel mechanisms into the Linux kernel, including Process management, Thread management, Object management, virtual memory management, Synchronization, System calls (Syscall), Windows Registry, WDM (Device driver framework), Windows DPC mechanism, etc., to form a new kernel. Thus, the new kernel allows both Linux and Windows applications and device drivers to work directly without virtualization or emulation. Weee, a registry on Linux? WTH? I was so happy that Linux operating systems do not have such a crap. It really does not make any big difference whether you store user, host or name databases in LDAP, Registry (binary files), text files in /etc or whatever, it is just a storage, though being realized by different means; if you put stuff in there, you will certainly need some ways to clean it. AIX for instance uses LDAP-based Registry if I remember correctly. What really matters is what you put to run in kernel space. Having that said, I don't think I will run such a "full-featured" kernel ever ;-) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557788: ITP: libjson-c -- JSON manipulation library
Hello, JFYI: we already have yajl [1] in Debian proper, which is superior to libjson- c or any other existing JSON C implementation. Therefore unless you need the latter library as a dependency of another package, I don't see much gain to have it in Debian too. [1] http://lloyd.github.com/yajl/ -- pub 4096R/0E4BD0AB -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365427: RFH: apt-build -- Need new developer(s)
On Sunday 30 April 2006 01:42, Julien Danjou wrote: > Package: wnpp > Severity: normal > > Hi, Hello, > apt-build really lacks of support right now. > It works pretty well, but currently it is not capable to deal with > every particular case that it might encounter. > Many improvements could be done, mainly by using libapt-pkg-perl and > enhancing it (like adding new bindings), instead of using external > programs such as apt-get or apt-cache. Perhaps some bits from apt-build can e merged to sibling projects like apt-src, sbuild or similar. > I have no time and no interest in working on apt-build, since I never > used it. > I only wrote it as a proof of concept that Debian could work the way > Gentoo did. I'm not sure what you mean here, but Debian already has several tools to build, test and improve debian source packages. Just to name a few ... starting from [ the bare apt-get build-dep && --build, several -buildpackage, debuild, pbuilder, apt-src, sbuild and probably several unofficials like apt-fu ... and ending with the famous wanna-build/buildd/sbuild infrastructure along with dak ] > If you want to kick out Gentoo and source based distro, please consider > helping apt-build. These are really no good reasons and probably a loose bait, I doubt there is something or someone to kick out ;-) Again I'm not sure what the definition of source based distro is and what is Debian lacking exactly ;-) IMHO having tools to build the distro source packages implies being a source based distro, but Debian has always has such tools and infrastructures. I really can't think of other distribution on the Earth with so many build tools. > A project is already set up on Alioth. Good. No offence plase, but I realy do not see the point of having so many build wizards ;-) Consolidate please ;-) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319201: kiax in Debian (was Re: Problems rebuilding twinkle)
On Saturday 06 May 2006 21:44, Santiago Garcia Mantinan wrote: > > We pretty much just need to remove the iLBC and update debian/copyright. > > > > For extra marks we could link to the system provided libspeex/ libgsm & > > portaudio.. > > It seems that is already done: > > Version: 0.8.5-2 > Depends: libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.0), libgsm1 (>= 1.0.10), > libportaudio0, libqt3-mt (>= 3:3.3.6), libspeex1, libstdc++6 (>= 4.1.0), > libx11-6, libxext6 > > > George Danchev was talking to upstream to get something along those lines > > in the next upstream release, but I haven't followed anything since. > > Well, George, how did that go? For what I see the new version still carries > all the stuff we didn't want, including iLBC, so I suppose we should at > least remove iLBC from our source package. Upstream said that they distributing the stuff in kiax's lib/ because these libraries are not stable enough (sort of true, but we have sonames to handle these out) in addition that we can live without lib/ anyway. I sent them a patch (ca. November 05) against 0.8.4 to clean the iLBC stuff up. You can have it at: svn co http://svn.openfmi.net/dev/people/danchev/kiax which was not incorporated in 0.8.5 - reasons unknown for the time being. > I have tested it and we can remove the hole lib directory and the program > still compiles, so I guess we could have a source package without this > directory and that would make half of our problems go away, isn't it? > > What I don't know is what we'd loose by removing this directory, iLBC for > sure, but that was a wanted effect anyway. But there were some dirs there > like sox, portmixer, ... that we don't have as a shared lib, so... what > where those for? lib/portaudio/LICENSE.txt and lib/portmixer/LICENSE.txt sound terribly non-free: * Any person wishing to distribute modifications to the Software is * requested to send the modifications to the original developer so that * they can be incorporated into the canonical version. Thus no anonymous modifications are allowed (a-la send me a postcard games ;-), so render these bits as DFSG-compliant. > As for removing iLBC the source is not ready for that and still shows the > iLBC button and it is enabled, so if you choose it and make a call you get > in the console: > > ERROR: Codec not supported: 1024 > ERROR: Codec could not be created: 1024 > > I'll have to investigate this more, but this poses problems when loading a > config (iLBC should be changed to some other codec like gsm) and then in > the preferences window where we should either make iLBC not appear or at > least make it appear disabled. > > Thoughts on all this? My impression is that linking against libgsm we already have in Debian should be enough. I'm still not sure how to approach upstream that distributing (possibly) modified non-free code with their lib/ is pretty dangerous solution for them. P.S. upstream is CC'ed. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372579: ITP: pcopy -- Disk(partition)-to-Disk(partition) copying tool
Package: wnpp Severity: wishlist Owner: George Danchev <[EMAIL PROTECTED]> Package name: pcopy Version : 1.5-3 Upstream Author : Peter Eriksson URL : ftp://ftp.lysator.liu.se/pub/unix/pcopy/ License : GPL Programming Lang: C Description : Disk(partition)-to-Disk(partition) copying tool Pcopy is intended to be used when doing large disk(partition) to disk(partition) copying where dd is just too slow and error prone. Preliminary package: http://sponsors.debian.net/viewpkg.php?id=293 -- 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.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373173: ITP: sofia-sip -- an open-source SIP User-Agent library
Package: wnpp Severity: wishlist Owner: George Danchev <[EMAIL PROTECTED]> Package name: sofia-sip Version : 1.11.9 Upstream Authors : Pekka Pessi, Martti Mela, Kai Vehmanen URL : http://sofia-sip.org/ ; http://sofia-sip.sourceforge.net License : LGPL Programming Lang: C Description : Sofia-SIP is an open-source SIP User-Agent library, compliant with the IETF RFC3261 specification. It can be used as a building block for SIP client software for uses such as VoIP, IM, and many other real-time and person-to-person communication services. Sofia-SIP is based on a SIP stack developed at the Nokia Research Center. The SIP supported features and SDP Protocol Features in Sofia-SIP could be found at: http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html Currently several projects are using Sofia SIP library. Some of them are FarSight, Tapioca, Telepathy, and the Gaim plugin for SIP/SIMPLE. The source package will be split into the following binary packages: sofia-sip - SIP library utilities libsofia-sip-ua - SIP User-Agent library libsofia-sip-ua-dev - SIP User-Agent library development files libsofia-sip-ua-glib - SIP User-Agent library Glib bindings to Sofia-SIP is an open-source SIP User-Agent library. libsofia-sip-ua-glib-dev - SIP User-Agent library development files Glib bindings to Sofia-SIP is an open-source SIP User-Agent library. Upstream has already done most of the packaging job right, and that was injected into pkg-VoIP Team repository [1]. [1] http://svn.debian.org/wsvn/pkg-voip/ -- 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.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#540247: ITP: abi-compliance-checker -- tool for checking binary compatibility of shared libraries (was: Re: backward/forward binary compatibility checker)
--cut-- > > The wiki-page with the latest release of binary compatibility checker > > is http://ispras.linux-foundation.org/index.php/ABI_compliance_checker > > This looks like an extremely useful piece of software (in the past > I've thought "I wish there were a tool to do this" :)). I'll package > it for Debian. Hi, There is also icheck package available in Debian for some years, but it targets mainly C. Perhaps you can use it as a comparison tool when testing this one. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#304570: Code::blocks packaging
Hello Michael, I found your package on mentors archive, and I'm generally interested in uploading codeblocks to Debian archive, since I intend to use it. In fact we have already gave it a try and found it much lightweight and intuitive as compared to eclipse + CDT for instance and AFAICS reading that buglog there are quite some people interested in codeblocks package who are now using their own local ones. Packaging looks fine to, but some comments though: * I found some pieces of code which seem to be external projects (tinyxml, wxscintilla, both hosted at sf.net); a simple grep for `author' or `file by' would reveals these details. Also licensecheck (devscripts) would be helpful. So, these licences and copyrights should also be listed in debian/copyright file, which presumably is in machine interpretable format. However, having so much code duplication doesn't help security, so we would be better off approaching upstream and find ways to use these packages (not packaged yet) separately, and not carry them with codeblocks source tree. These could be sort of tedious and time consuming dealing with upstream. * I haven't looked at their trunk lately, but is there any progress on sorting out that `global plugins path' hack you have applied to the package ? * I also think that such a tremendous package as a codebase should be maintained by a team, ubuntu guys are also welcome of course. Any suggestions ? [1] http://wiki.debian.org/Proposals/CopyrightFormat -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450873: RFH: command line CD-R/CD-RW writing tool
Package: wnpp Severity: normal I request assistance (co-maintainers) with the cdrskin package. It needs a lots of testing on different drives and architectures. It also worth thinking of splitting off libburn and libisofs binary packages from cdrskin source package eventually to replace the already existing and badly outdated libburn-1, libburn-dev, libisofs-1, libisofs-dev packages. The upstream is very responsive and cooperative. The packaging files are currently hosted in collab-maint [1]. [1] svn.debian.org/svn/collab-maint/deb-maint/cdrskin -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450876: RFH: ara -- utility for searching the Debian package database
Package: wnpp Severity: normal I request assistance with co-maintaining the ara source package. The package is in a good shape, but there are few wishlists bugs left in BTS, which need an experienced ocaml hacker to look at. Thanks. ara is hosted at svn.debian.org/svn/ara -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450876: RFH: ara -- utility for searching the Debian package database
On Sunday 11 November 2007, Samuel Mimram wrote: > Hi, > > George Danchev wrote: > > Package: wnpp > > Severity: normal > > > > I request assistance with co-maintaining the ara source package. The > > package is in a good shape, but there are few wishlists bugs left in BTS, > > which need an experienced ocaml hacker to look at. Thanks. > > > > ara is hosted at svn.debian.org/svn/ara > > Maybe could we maintain it collaboratively within debian-ocaml-maint? Hello Samuel, It is not the repository that matters, the current one is just fine... also ara has a pretty nice web page at http://ara.alioth.debian.org/, so I believe we don't need reorganisation right now, but looking at the common/cli/gui code and cleaning it up ;-) I guess that Berke won't mind to add more developers with write access to the current ara svn repo who are ready to improve the code. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450876: RFH: ara -- utility for searching the Debian package database
On Monday 12 November 2007, Berke Durak wrote: > On Sun, Nov 11, 2007 at 11:37:43PM +0100, Stefano Zacchiroli wrote: > > On Sun, Nov 11, 2007 at 11:34:20PM +0100, Berke Durak wrote: > > > So who wants what access on the Alioth account, what do I have to do? > > > > What about enlarging the write permission of your repository to all DDs > > as described in [1]? > > So I have to ask the alioth admins? George, Samuel: you are also admins > on the ara project, could you ask them? Or do I have to ask? (It seems > I don't have any special status on the ara project). Sure, I asked alioth svn admins to DD-widen (that's should be a new verb, right ;-) ara svn permissions. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450876: RFH: ara -- utility for searching the Debian package database
On Monday 12 November 2007, George Danchev wrote: --cut-- > Sure, I asked alioth svn admins to DD-widen (that's should be a new verb, > right ;-) ara svn permissions. This mirning Raphaël Hertzog informed me that we now have DD-widen svn repo for ara. Thanks to alioth admins. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Bug#433325: RFA: kbedic -- K Bulgarian/English Dictionary
Grant, Are you still interested in adopting kbedic. If so (which is the preferred variant for me), I can offer sponsorship and bulgarian knowledge when needed, otherwise I'll seek ways to adopting it myself. -- 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/20100613120431.13926xrdchz2b...@webmail.spnet.net
Bug#433325: RFA: kbedic -- K Bulgarian/English Dictionary
Quoting "Grant Hammond" : Hi George, Hi, Thank you for your offer of sponsership. Sorry, I have been a bit lazy here. However, I am still interested in these packages. Since I primarily use GTK based desktops it might make more sense for a KDE user to take on kbedic. In which case I'll certainly not stand in anyone's way but I would like to help out either way. Okay, apparently I forgot about kbgoffice [1], which is already based on qt4. Basically it is kbedic codebase migrated to qt4. Today I sent a couple diffs to the upstream maintainer which deal with newer (pickier) compiler. After getting feedback from him, I'll package it, so we can leave original kbedic rest in piece post-squeeze. [1] http://bgoffice.sourceforge.net/ (sorry, bulgarian, only, but translate.google.com should help with translation) -- 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/20100614131140.12634ysih3o4p...@webmail.spnet.net
Bug#319201: Fwd: kiax_0.8.4-3_i386.changes REJECTED
On Saturday 01 October 2005 03:33, Mark Purcell wrote: > George, Hello all, > We have setup a shared working enviroment at > http://svn.debian.org/wsvn/pkg-voip/kiax is you would like to help out > directly with the Debian package. > > You can request an account at http://alioth.debian.org and then we can set > you up with svn commit access. Sure. I have been registered alioth user since 2004-10-27. My login name is danchev-guest and I agree to help out as much as I can. I'll join the mailing list also. On Wednesday 28 September 2005 00:49, Joerg Jaspert wrote: > Hi Maintainer, > > sorry, rejected for now. > The source contains lib/iLBC, which at least has a rfc3951.txt, which > license is non-free. Also all the other source files there state a (C) by > Internet Society (2004), *All Rights Reserved*. Looking at the name i doubt > its free, and searching for the library name got me to a site, having a > license link[1][2] which starts so horrible non-free that I stopped reading > it. Good catch. We have missed that one within the upstream tarball of kiax-0.8.4.tar.bz2 as found at SF. I will ask debian-legal for advise about iLBC but as a freeware license [1] it doesn't sound good enough even the redistribution is allowed since it limits the commercial use at least. Anyway that's an iaxclient issue shipped with the upstream kiax tarball (the lib/ directory), but we have already had iaxclient packages in Debian archive (iaxclient-0.0+cvs20050725) without lib/iLBC. While looking at the kiax 0.8.4 sources I realized that it can compile with the lib/ directory from iaxclient-0.0+cvs20050725 debian source package (which I believe is DFSG'ed). In fact it did and works, but that needs a close investigaton to see what we lose without iLBC. I would like to follow the shared library way Mikael Magnusson suggested at bug #319201 and build depend on libiaxclient-dev while educate kiax of using it. > Next issue is that your debian/copyright is wrong, its missing a bit > of license information. You need to list *all* different copyright holders > and licenses that are in your sourcepackage. > Missing are at least lib/libspeex (which has at least 2 different licenses, > maybe more)., Agreed. I had a look at excellent iaxclient-0.0+cvs20050725/debian/copyright file and it also doesn't mention lib/libspeex copyright holders and licenses. I believe it should be fix there also. > While Im at it: > debian/README.Debian is pretty useless atm, could be removed. Will be revised and if still empty will be removed. Thanks. > [1] One of the few links that were readable, the rest of the site is hidden > behind stupid flash-stuff. > [2] ilbcfreeware.org. Lets hope its the right site for this lib, but > looking at the purpose of the lib and the text of the site and what its for > I simply assume this. I would also suggest kiax authors to follow the comments if the Global IP Sound iLBC Public License, v2.0 - IETF Version is a really (non)-free license at: http://lists.debian.org/debian-legal/2005/10/msg0.html will help avoid possible legal issues concerning the project ;-) > If you get these points fixed/cleared you can go in, but for now you are > out. :) Absolutely agreed and we hope to survive ;-) Sorry for wasting your time with missing legal/license notes and URLs. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319201: Fwd: kiax_0.8.4-3_i386.changes REJECTED
On Monday 03 October 2005 01:21, Mark Purcell wrote: > On Sunday 02 October 2005 20:26, George Danchev wrote: > > Sorry for replying to myself, but I would like to get some advices of how > > to proceed from now on. The kiax 0.8.4 [1] issues read: > > George. Thanks for your continued work on this. Please keep it up! > > > 1) lib/iLBC - lisenced under Global IP Sound iLBC Public License, v2.0 - > > IETF Version which is non-free [2] - will be tricky, but doable I think. > > I think it needs to be removed from any dfsg archive. We are allowed to > remove non-free components from the .orig.tar.gz in order to achieve this. > > The iaxclient README seems to have it right. iaxclient can be built and > peforms well with either/ both libspeex and iLBC. iLBC is potentially > non-free, thus iaxclient is only distributed with libspeex. (Note there is > a patch required from the upstream libspeex for iaxclient support) Yes. iLBC is horrible non-free piece as said by ftpmaster and seconded by -legal. > We can do the same with kiax, only distribute with libspeex. Although > ideally kiax should be setup to just use the shared libraries provided by > libiaxclient-dev. I see. I also sent a patch to upstream yesterday sanitisizing kiax tarball's lib directory and fixing the ilbc mess in 0.8.4. Got replies from them and seems they respect my arguments and the next new upstream version of kiax will we be clean..., will see. The shared library approach is a little bit hindered by these libraries not haiving versioning upstream. In fact kiax cvs code is meant to compile without any lib/ directory and linking with the iaxclient library already installed, but I dont want to go for cvs-dated source packages for the time being. We will keep working to deal with all these issues upstream as much as possible in the next release / at least we share the same native home language upstream ;-)/ > > 2) populate debian/copyright with all copyright holders and licenses > > including the Speex Licences. But if we go for educating kiax of using > > system libraries provided by already existing packages then we do not > > need that - that's also kind of tricky part since iaxclient also > > provides libspeex library itself. > > Correct. We actually also need to update debian/copyright for iaxclient as > well, as it doesn't detail the copyright for libspeex either and it also > distributes it. I have just filed a severity serious bug report. > > I have also filed a bug against iaxclient to remind ourselves to use the > shared libspeex when we can. (Encorporation of iaxclient patch) I'll try to approach kiax using existing speex also. > > 3) README.Debian - easy. > > Great! > > > Now my question is does something like above will save 1) in a reasonable > > way ? I think that the program will be still useable when built against > > such 'sanitisized' lib. So the kiax's lib/ (as found in dfsg.orig.tar.gz) > > should be sanitisized to the lib/ found in iaxclient-0.0+cvs20050725 > > source package. > > Yes stripping out the lib/ to only include dfsg and renaming the tarball > to .dfsg is is a perfectly reasonable approach, and would appear to be > workable. I see. This was the way to go before getting a notion of the new and clean, possibly all-free upstream prospective release from kiax's authors. I prefer to deal that upstream when possible. > > > > Does this affect Asterisk? > > Having a look yes it does! > > asterisk does distribute codecs/ilbc, but debian/copyright doesn't list the > copyright holder :-( > > So at least debian/copyright needs to be updated, but potentially > codecs/ilbc needs to be removed from the asterisk-xxx.dfsg.tar.gz. I have > just filed another severity serious bug against asterisk. Well yesterday I was told that having ilbc bits in asterisk have been the very reason for the kiax's upstream getting it in their tarball. Seems we can work out that with the kiax authors soon... I'll keep'em close and feed with patches if necessary. Hope the same will happaned esily to the asterisk upstream. > > > Well I think it is DFSG-compliant since at least the tarball name > > > suggests that like dfsg.X.orig.tar.gz, although there should be a note > > > about removed non-free files in copyright file or README.Debian I'm > > > missing here ? > > Hmm, the dfsg. name doesn't mean we removed all non-free software, just > some of it. In particular the non-free music-on-hold. Perhaps we need to do > an audit against all the asterisk code base, although upstream are claiming > the .tar is GPL compliant! I see. Sometimes upstream are terribly wrong. > > > That is
Bug#332858: ITP: cvsup -- The CVS-Optimized General-Purpose Network File Distribution System
On Sunday 09 October 2005 03:10, Henning Makholm wrote: --cut-- > > The CVSup requires Modula-3 compilator to build, so also I'm > > planning to package Ezm3 - An Easier Modula-3 Distribution, which is > > designated to compile CVSup only. > > Best of luck with that. Torsten might still be interested, too. CVSync [1] is a possible alternative to CVSup, not compatible with it, but written in plain C. [1] http://www.cvsync.org/ -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332858: ITP: cvsup -- The CVS-Optimized General-Purpose Network File Distribution System
On Monday 10 October 2005 16:45, Javier Fernández-Sanguino Peña wrote: --cut-- > > CVSync [1] is a possible alternative to CVSup, not compatible with it, > > but written in plain C. > > That one looks interesting, I did not find it when I was googling for > alternatives to CVSup. I would love to see something like this packaged so Someone should at least hint wnpp then ;-) > that we could distribute copies of our CVS worlwide and not have issues if > we have any issues with the servers holding our CVS in the future. I find rsync being enough for mirroring CVS repos. Yes, I'm familiar with CVSup usage of the rsync algorythm for some files and some special algorythms tailored for rcs files, but I don't think that could be a showstopped for mirroring CVS repos with rsync only. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290364: ITP: svn-arch-mirror -- one-way mirroring from Subversion to Arch revision control
On Thursday 13 January 2005 21:42, Eric Wong wrote: > Package: wnpp > Severity: wishlist > > > * Package name: svn-arch-mirror > Version : 0.2.6 > Upstream Author : Eric Wong <[EMAIL PROTECTED]> > * URL : > http://des.petta-tech.bogomips.org/eric/MusicPD/[EMAIL PROTECTED] >normalperson/svn-arch-mirror/ * License : GPL v2 > Description : one-way mirroring from Subversion to Arch revision > control > > svn-arch-mirror makes it possible to track upstream Subversion > repositories and replicate full project history from Subversion to Arch. > Features include: > - preserving the date and time of the original commit > - preserving the alias/name of the original committer > - intelligent branch-tracking Seems to be a nice piece of software. Since there is cvs2svn [1], I would suggest to rename svn-arch-mirror as svn2arch (both upstream and debian package). [1] http://cvs2svn.tigris.org -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Bug#319201: kiax Debian packages
On Wednesday 20 July 2005 17:06, Mark Purcell wrote: > George, Good day Mark, > I have just been using your Debian packages of kiax, a very nice user > interface and one of the best I have seen under Linux. > > I'm actually the Debian GNU/Linux maintainer of asterisk and I think it > would be useful to have kiax in the main Debian distribution, rather than > only available via a sf.net download. > > We also have a pkg-voip-maintainers group who are looking after the broad > range of VoIP applications and a svn archive at > http://svn.debian.org/wsvn/pkg-voip Right, having kiax in official debian archive is good. > Can we take your packaged version of kiax and upload to the Debian unstable > distribution? I couldn't find you .diff files anywhere, have you uploaded > them or can you email? Perfect ! You can find my work at: as a source package under revision control: svn co http://svn.openfmi.net/debian-addons-bg/trunk/kiax as a source and binary package in an apt repo: ftp://ftp.uni-sofia.bg/debian-addons-bg/dists/sid/kiax/ ftp://ftp.logos-bg.net/debian-addons-bg/dists/sid/kiax/ relevant sources.list entries: deb ftp://ftp.uni-sofia.bg/debian-addons-bg ./ deb-src ftp://ftp.uni-sofia.bg/debian-addons-bg ./ deb ftp://ftp.logos-bg.net/debian-addons-bg ./ deb-src ftp://ftp.logos-bg.net/debian-addons-bg ./ You may want to review and polish it a little bit. Thanks to you and the Alioth's pkg-voip group for your maintenance. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB pgpXPGY7uGed4.pgp Description: PGP signature
Bug#293691: schedtool
On Saturday 03 September 2005 23:57, Janne Kujanpaa wrote: --cut-- > > Personally I don't see much that schedtool offers over schedutils. > > SCHED_ISO, SCHED_BATCH and better documentation for program usage and > new schedulers. Some people prefer vim and some other emacs. Right. Also we have many examples of different packages providing almost identical functionality but anyway not the same. There is no accounting for tastes.. tricky ones ;-) > > Well the package looks fine to me, so if you want I have no objections > > sponsoring it. Good to know that. > I'll wait for version 1.3.0. Agreed. Anyway we can talk to unit-linux upstream to replace rml's code with schedtool at some point, but I do not think it is of any importance since I expect/believe there would be more userland code like these in the future. > > Also of interest is bug 322883. You might want to talk to util-linux > > upstream about merging schedtool with schedutils. > > I checked util-linux version 2.12q and there wasn't code from schedutils. it is in 2.13* into the testing/ directory. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290364: ITP: svn-arch-mirror -- one-way mirroring from Subversion to Arch revision control
On Thursday 13 January 2005 21:42, Eric Wong wrote: > Package: wnpp > Severity: wishlist > > > * Package name: svn-arch-mirror > Version : 0.2.6 > Upstream Author : Eric Wong <[EMAIL PROTECTED]> > * URL : > http://des.petta-tech.bogomips.org/eric/MusicPD/[EMAIL PROTECTED] >normalperson/svn-arch-mirror/ * License : GPL v2 > Description : one-way mirroring from Subversion to Arch revision > control > > svn-arch-mirror makes it possible to track upstream Subversion > repositories and replicate full project history from Subversion to Arch. > Features include: > - preserving the date and time of the original commit > - preserving the alias/name of the original committer > - intelligent branch-tracking Seems to be a nice piece of software. Since there is cvs2svn [1], I would suggest to rename svn-arch-mirror as svn2arch (both upstream and debian package). [1] http://cvs2svn.tigris.org -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293691: ITP: schedtool -- cpu schedule policy tool
On Saturday 05 February 2005 03:55, Janne Kujanpaa wrote: > Package: wnpp > Severity: wishlist > > > * Package name: schedtool > Version : 1.2.4 > Upstream Author : Freek > * URL : http://freequaos.host.sk/schedtool/ > * License : GPL2 > Description : cpu schedule policy tool > > It can be used to avoid skipping for A/V-applications, to lock > processes onto certain CPUs on SMP/NUMA systems, which may be > beneficial for networking or benchmarks, or to adjust nice-levels > of lesser important jobs to maintain a high amount of interactive > responsiveness under high load. There has been schedutils package already in testing and unstable archive for a long time, but seems like schedtool(8) has more features than chrt(1) and taskset(1) from schedutils package. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#679249: RFH: libburn -- library to provide CD/DVD writing functions
Package: wnpp Severity: normal I request assistance with maintaining the libburn package. I currently lack the sufficient time, and burning devices to provide adequate testing of its optical burning capabilities, although the software is in quite mature state. In this case the burning applicaiton is cdrskin. Upstream is responsive. There is an alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libburn is a library for reading, mastering and writing optical discs. Supported media are: CD-R, CD-RW, DVD-RAM, DVD+RW, DVD+R, DVD+R/DL, DVD-RW, DVD-R, DVD-R/DL, BD-R, BD-RE. -- 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/20120627124802.17218.26501.reportbug@sid
Bug#679254: RFH: libisofs -- library to create ISO9660 images
Package: wnpp Severity: normal I request assistance with maintaining the libisofs package. I currently lack the time to maintain this package alone. The major drain of time is following various image specs, following the upstream VCS, and further discussions. One interesting aspect is that libisofs links with libjte in order to produce jigdo representation at the same time while producing the iso image itself (state stable). Further developments are ongoing to produce ISO9660/HFS(+) hybrids, see #630351 for some details, which is also of interest of debian-cd task (currently performed by genisoimage for Debian PowerPC images offered) This would take quite some effort in testing and proving it correct. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: libisofs creates ISO images which can then be burnt with cdrskin or other software. -- 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/20120627130139.17765.29666.reportbug@sid
Bug#679265: RFH: libisoburn -- command line ISO-9660 and Rock Ridge manipulation tool
Package: wnpp Severity: normal I request assistance with maintaining the libisoburn package. I currently lack the time to maintain this package alone. This includes a high-level library along with a versatile app called xorriso for burning and image production. It has grown a tremendous amount of options, to the point of being "language" interpreter on its own right, also featuring other program option personalities (like these of mkisofs, cdrecord). This is the hardest part to thoroughly test. Debian-cd image production is in the hands of xorriso, except for the PowerPC images due to lack of ISO9660/HFS(+) support which is currently emerging. Upstream conversations and following upstream VCS are almost a must. Upstream is responsive. The alioth project could be reached at: pkg-libburnia-de...@lists.alioth.debian.org Co-maintainers welcome. The package description is: xorriso is a command line and dialog application, which creates, loads, manipulates, and writes ISO-9660 file system images with Rock Ridge extensions. . It maps file objects from POSIX compliant file systems into Rock Ridge enhanced ISO-9660 file systems and features session-wise manipulation of such file systems. It can load the management information of existing ISO images and write the resulting session to optical medium or as file system objects. . Supported optical media types: - CD-R, CD-RW - DVD-R, DVD-R DL, DVD-RW, DVD+R, DVD+R DL, DVD+RW, DVD-RAM - BD-R, BD-RE . Some interesting features: - Emulation of the mkisofs and cdrecord programs. - Data backup and restore capabilities - compression, ACLs, and filters. - Isohybrid MBR with partition offset - features booting ISOLINUX from USB sticks, or from other devices that appear to PC-BIOS as hard disks. The images carry a conventional partition table for a USB stick; the first partition reports the size of the ISO image, but starts at a non-zero address. It is nevertheless still mountable. - Jigdo Template Export - jigdo representation of the resulting ISO-9660 image, generated on the fly. . Test suite: xorriso source code comes with a release engineering test-suite called `releng', which aims to cover most of the functionality of the xorriso and the underlying libraries of libburn, libisofs, and libisoburn. -- 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/20120627131407.18171.20759.reportbug@sid
Bug#360519: RFP: tapioca -- framework for VoIP and Instant Messaging (SIP and google interoperable)
Hi, Just to let you know that sofia-sip library is already in the official Debian archive[1]. You may proceed with packaging tapioca and tapioca-sip which depends on sofia-sip library. I don't use tapioca, but it seems nice, so tell me if you need assistance. Btw, do you know how far FarSight.sf.net is currently and is it mature and useful enough to be packaged also ? http://packages.qa.debian.org/s/sofia-sip.html -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386060: ITP: c++-annotations -- The C++ Annotations tutorial by Frank B. Brokken
On Tuesday 05 September 2006 13:21, Hamish Moffatt wrote: > On Tue, Sep 05, 2006 at 12:33:56AM +0200, Frank B. Brokken wrote: > > The C++ Annotations are a tutorial intended for knowledgeable users of C > > (or any other language using a C-like grammar, like Perl or Java) who > > would like to know more about, or make the transition to, C++. The C++ > > Annotations do not cover all aspects of C++. In particular, C++'s basic > > grammar, which is, for all practical purposes, equal to C's grammar, is > > not covered. The various C++ topics are covered in the following > > chapters: > > Hi, Hello, > This sounds interesting but why is it useful to have a package? Well, because it is easier for Debian users to search for, install, upgrade such books. Basically on the same line wrt packaging are the c-cpp-reference package (although not being so exhaustive) and ocaml-book-en|fr (being a very serious book, but unfortunately in non-free). -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#360519: Telepathy, FarSight and Tapioca
Hello, Is there an interest and manpower Telepathy [1], FarSight [2] and Tapioca [3] to be packaged for Debian. There is an ITP #360519 filed only for Tapioca though. Note that all of these can use the Sofia SIP library [4] we already have packaged and maintain for Debian together with its upstream. [1] http://telepathy.freedesktop.org/ [2] http://farsight.sourceforge.net/ [3] http://tapioca-voip.sourceforge.net/wiki/index.php/Tapioca [4] http://wiki.opensource.nokia.com/projects/SofiaApplications -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372579: ITP: pcopy -- Disk(partition)-to-Disk(partition) copying tool
On Wednesday 18 October 2006 12:18, Aníbal Monsalve Salazar wrote: > On Sat, Jun 10, 2006 at 02:37:09PM +0300, George Danchev wrote: > > Preliminary package: http://sponsors.debian.net/viewpkg.php?id=293 > > After packaging pcopy, I noticed that you already have > packaged it. I compared mine with yours and found some > diferences. Ah such things just happend sometimes ;-) > The size of your .diff.gz is 25613 and mine is 2605. > You don't need to depends on coreutils. That is correct. I also wrote a moderate manpage you might have wirtten too. > IMO, I think my package is slightly better. I just > upload it. Sounds great to me. > If you would like to be a comantainer, please let me > know. Sure. I'm still in the NEW queue, but I have write access to svn://svn.debian.org/collab-maint/ so we can comaintain the package there or you have any other VCS repo in mind ? Did you talk to upstream so far ? I've tried to do so twice, but I've never got a reply. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB pgpgGIb3GOgvF.pgp Description: PGP signature
Bug#679254: [Pkg-libburnia-devel] libisofs
Just bouncing this one to serve as a reference, since I forgot to do it in the first place when replying. Further discissions will take plane in the pkg- list. On Wednesday 01 August 2012 21:28:22 bash.d wrote: > Hello, George Danchev, > > I would like to help you maintaining the libisofs-package. > I already replied to the BTS entry, but have not yet received any > response. If you are interested, please answer me. > Thank you and regards, Hi Sebastian, [I added pkg-libburnia-devel@ in CC, where Thomas Schmitt is also subscribed] Thank you for your offer to help, it is really appreciated. It is of course my fault of not paying attention close to RFH#679254, but you did it right pinging my on private. Thanks! The three libraries of libburn (RFH#679249), libisofs, and libisoburn (RFH#679265) are best to be maintained together, and involve quite some interaction with upstream, which is fortunately very responsive and helpful. See http://libburnia-project.org for details, and the upstream list is libburn-hack...@pykix.org. For libisofs in particular, there is an effort to complete the hybrid fs part, which involves HFS+ (see libisofs/hfsplus*.c|h in bzr) and HFS (no plus) - no code yet. ISO9660/HFS hybrid is used for the production of Debian PowerPC images, and in order to replace the old and almost unmaintained genisoimage, it would be nice to have this one properly implemented, verified and deployed. (actually these are HFS#630351 and UDF#630863, the latter being a goal in the distant future). The libburnia libraries are covered by in-house test suite called 'releng': See, README, TODO and CHECKLIST, as well as the code at: http://libburnia-project.org/browser/libisoburn/trunk/releng Extending and running this test suite is a good way to build trust that no or less regressions would occur. Then comes the debian-cd task, which is the largest "stress-test suite" for xorriso (and resp. libisofs in particular) currently known to us, so it is also nice to pay attention to debian-cd BTS record for relevant bugs, the debian-cd mailing list for relevant complaints, and debian-cd live logs as well: http://cdbuilder.debian.org/cdimage-log/ (also see analysis.html) Last, but not least, it is also nice to try to help applications which are trying to make proper use (or resp. abuse) of libburnia libraries to find their way. For instance, see brasero BTS record. To summarize: there is a plenty of code work, thrice as much testing and bug triaging and sorting out (coupled and decoupled) issues or non-issues... and I'm pretty sure Thomas can add some more points as well. While it is true that libburn/libisofs/libisoburn currently bear almost perfectly clean BTS log record, it took, takes, and will take a fair amount of time to preserve this state as it is. So, feel free to pick your niche to contribute to the project :) -- pub 4096R/0E4BD0AB -- 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/201208021228.58317.danc...@spnet.net
Bug#450876: Orphaning ara
retitle 450876 O: ara -- utility for searching the Debian package database thanks I'm hereby orphaning ara, due to lack of time and limited usage of it on my side. The package description is: Command line utility for searching the Debian package database ara is a utility for searching the Debian package database using boolean regexp queries. ara can perform sophisticated searches on that database. It is possible to use any field of the package database as a search criterion and any boolean combination thereof. ara can also call APT (or any user-configurable command) to install or remove packages matching a query. There is also a separate alioth project for it: https://alioth.debian.org/projects/ara/ as well as a webpage http://ara.alioth.debian.org/ Perhaps ara is best to be added to the git repo of Debian OCaml Task Force. If you adopt this package, you should also adopt it upstream. -- pub 4096R/0E4BD0AB -- 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/201112091556.57956.danc...@spnet.net
Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Friday 06 May 2011 19:39:26 Tshepang Lekhonkhobe wrote: > On Fri, 2011-05-06 at 13:24 -0300, Ben Armstrong wrote: > > On 05/06/2011 12:14 PM, Tshepang Lekhonkhobe wrote: > > > Q: How many content management systems written in php does Debian need? > > > A: How about zero? > > > > > > Not exactly helpful. > > > > When developers are passionately opposed to a particular technology (and > > not without reason here, I think,) they can be a bit blunt in expressing > > it. The list of these goes on and on ... and while I certainly would be > > more polite myself about expressing reservations about adding any more, > > I'm not going to fault others for expressing their dissent. The way you > > expressed your support seemed to me to gloss over the real cost of > > adding a new package to the archive without any coherent argument as to > > why this particular one was going to be no trouble at all (and/or worth > > the trouble because it's so special). > > Strange that you read 'support' into my responses. Actually I have never > even heard of the proposed package, but that's not the point. I even > mentioned that if the package sucketh (if the guy proposing it proves > unreliable), then it can either remain in Unstable or be removed. Upload to 'unstable' and see how it goes could be quite suboptimal tactics most of the time. I'm not talking about that particular package, but not every package which flies in the free software skies deserves to be in Debian archive in my own opinion. Inclusions costs human time. > You don't just blatantly oppose Debian inclusion without mentioning why. > The great Josselin Mouette (yes, I really respect this guy for his > tireless GNOME maintenance) just did that, and the rest of us are > supposed to magically possess the history of PHP in Debian, and laugh it > off. > > And no, you should fault others for expressing their dissent in this > unproductive manner. Well, maybe if you look at that from a different angle, you can find it productive as in: don't spend your time packaging that particular one, as chances are very low for upload. -- pub 4096R/0E4BD0AB -- 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/201105062003.43593.danc...@spnet.net
Bug#796145: O: libburn -- command line CD/DVD/BD writing tool
Package: wnpp Severity: normal I intend to orphan the libburn package. I simply don't have the time and energy to maintain it. The package description is: cdrskin strives to be a second source for the services traditionally provided by cdrecord. Currently it does CD-R and CD-RW this way. Overwritable media DVD-RAM, DVD+RW, DVD-RW, and BD-RE are handled differently than with cdrecord-ProDVD in order to offer TAO-like single track recording. Sequential DVD-R[W], DVD+R, DVD+R DL are handled like CD-R[W] with TAO and multi-session. Additionally cdrskin offers cdrecord-ProDVD-like mode DAO with DVD-R[W]. . This is a burner only application. If you want a burner and image manipulation application, please install xorriso package.
Bug#796147: O: libisoburn -- debugging symbols for libisoburn and xorriso
Package: wnpp Severity: normal I intend to orphan the libisoburn package. I simply don't have the time and energy to maintain it. The package description is: libisoburn is a frontend for the libraries libburn and libisofs. It handles the creation, loading, manipulation and burning of ISO-9660 filesystem images. This library provides a low-level API, called libisoburn API, which encapsulates the API of libburn and libisofs, and a higher level API, called xorriso API which encapsulates the API of libburn, libisofs, and libisoburn, and is also used by the xorriso program itself. . This package contains debugging files useful for investigating any problems with the binaries found in the libisoburn library and the xorriso application.
Bug#796146: O: libisofs -- debugging symbols for libisofs
Package: wnpp Severity: normal I intend to orphan the libisofs package. I simply don't have the time and energy t maintain it. The package description is: libisofs creates ISO images which can then be burnt with cdrskin or other software. . This package contains debugging files used to investigate problems with binaries included in the libisofs packages.
Bug#796145: Adoption
On Sunday 30 August 2015 12:15:38 J.S.Júnior wrote: > I want adoption this package > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796145 > > Or, help you. > > But you send RFH > > []`s Excellent! Thanks for your interest. libburn, libisofs, libisoburn are team-maintained, so please have a look at the pkg-libburnia project on alioth. Bonus, Thomas Schmitt (in CC:) who is also upstream of these has recently joined the packaging projects as well as the mailing list. I'm pretty sure he would appreciate some Debian packaging help. -- pub 4096R/0E4BD0AB
Bug#304570: CodeBlocks upload rejected?
On Sunday 08 March 2009 23:06:36 Steve M. Robbins wrote: > Hi, Hi, > This bug has a very long history :-) > > The entries of 2008-10-29 and 2008-12-07 suggest that the package was > uploaded then rejected. What is the problem? How can I help get > CodeBlocks into Debian? I left some traces on that bug, but I didn't uploaded the package, thus I have no clue what the reasoning behind that rejection was, though I'd like to know too. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
