Spout package ready for upload (ITP with Bug#356492)
I am answering my own message because I realise I failed to include an important bit of info: I am looking for a sponsor for Spout. It is a tiny black and white caveshooter that runs on top of SDL, As you can read in the relevant bug (#356492), a .deb package exists, and it is DFSG-free, policy-compliant and lintian clean. You can check out Spout at: http://rowrcolo.net/~kandinski/packages/spout/ Regards, -- javier candeira -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: bfilter, aspell-hr, myspell-hr
Mailed to mentors, we like to do stuff in public and I don't claim to be infallible, either. ;-) On Tue, May 30, 2006 at 02:09:49AM +0200, Vedran Fura? wrote: > Kari Pahula wrote: > > As far as the technical side of packaging goes, it seems to be mostly > > in a good shape. One thing you should see about is not compiling > > statically the included libraries (boost and libjs, at least) but > > using the shared libraries in Debian already. It would save space on > > users' systems and is a good practice securitywise. > > > > Try to make a patch to send to upstream about this change. I'm sure > > they wouldn't mind having optional configure switches to not build the > > included libraries and using the ones present on a system. It would > > save your workload in the long run, too. > > I mailed him, here is his response: > > "That can be done, and I am willing to do it if debian/ubuntu teams > insist on it, but this solution has its problems: I was thinking of a configure option to not compile the included libraries but to use the ones present on the system already and leave as the default behaviour what bfilter's build system currently does. > 1. Nobody wants an extra dependency, especially when it's bigger than > the package itself. We have apt, which can easily fetch any dependencies. This argument really applies to people who compile software from source. A valid concern for an upstream, which is why I would be happy to leave as the default behaviour what their build system currently does. > 2. When I ship boost (actually just a fraction of it) as part of > bfilter, I can be sure that the version I ship doesn't have bugs (at > least visible ones). It was more than once when I had to apply a patch > after reporting a bug upstream and getting either "Fixed, here is a > patch" or "Already fixed in CVS" responses. Also, sometimes they > introduce new bugs, so I can't be sure that the next boost release > doesn't break bfilter. That goes the other way around too. Any security bugs that are found in boost or other statically linked libraries will remain unfixed until bfilter itself is recompiled. The boost packages in Debian are patched independently of upstream, so the fixed-in-CVS issue is less so around here. > 3. You are not going to save memory by linking to a dynamic library, > because: > a) There are few programs that use boost, so sharing memory is unlikely. > b) Most of boost is template code, which ends up in the executable > anyway." The security issues are really more important than the memory or disk usage savings. > Should I insist? No. There are few issues that really require insisting anything in maintaining packages, and this one isn't one of them. Licensing issues can require changes from the upstream, as well as SONAME hygiene with libraries. Most things can be done in diff.gz (or with patch system of your choice) and if they patch is in a nice enough shape to send to upstream, then it is a good practice to do so. Try to see if you could get bfilter patched yourself to use Debian's libjs and boost but if it looks like it would lead to too much madness then just leave it as is. Be mindful that doing so would lead to more source code that you'd be responsible mostly yourself to fix when and if it breaks. > > You need to list all copyright holders and the years involved, even > > for the libraries included in the upstream source tarball. See > > http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html > > > > I see that the debian/copyright file might get quite long in this > > case. However, it is necessary. That'll make FTP masters happy and > > you don't want to make them unhappy. And no, repackaging the > > .orig.tar.gz file to remove those libraries just to avoid having to > > list their copyrights is not the way to go, either. > > You mean something like this: > $ grep -rih copyright bfilter-1.0.2/ | sort -ufi > ...is the right way? Yes, quite long. I'd do something like this: Copyright 1234 Author (License of bfilter itself) bfilter includes libfoo Copyright 5678 Author of libfoo (License of libfoo) bfilter includes libbar Copyright 0010 Author of libbar (License of libbar) etc. signature.asc Description: Digital signature
Re: Question about linux-wlan-ng-firmware in main
On Mon, May 29, 2006 at 09:40:01PM +0200, Goswin von Brederlow wrote: > Simon Richter <[EMAIL PROTECTED]> writes: > > > Hi, > > > >>>As I understand it, the sole purpose of this package is to download > >>>non-free firmware. This fits into 'contrib', not 'main', since it > >>>depends on non-free software for its ultimate operation. Packages > >>>like this are given as an example of packages for contrib. From > >>>Policy 2.2.2: > > > > Hm, that is close to the case of mISDN's "loadfirm" utility. The > > consensus back then was that splitting off a (free) firmware loader > > from a free package was not worth the effort required (after all, > > we're not violating licenses here); also IMO it is a bit > > counterproductive, as people wishing to write free firmware would have > > to get the firmware loader from contrib then. > > > > Simon > > But does it have any use without the non-free firmware? Only then can > you close an eye and let it stay in main due to its other functions. Sure. Only few models really need the firmware. For example my DWL-122 USB stick works fine without the 'non-free' firmware. Thanks for the answers. -- Enrico Tassi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Real Life hits: need to give up packages for adoption
also sprach martin f krafft <[EMAIL PROTECTED]> [2006.05.29. +0200]: > also sprach <> [2006.05.29.2129 +0200]: > > * python-docutils > > (easy pickings) > > I'd like to take that on. I am already co-maintainer. Other > co-maintainers welcome. And surely, if some NM or candidate wants to pick this up, I can sponsor. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "wahnsinn bei individuen ist selten, aber in gruppen, nationen und epochen die regel." - friedrich nietzsche signature.asc Description: Digital signature (GPG/PGP)
Re: Question about linux-wlan-ng-firmware in main
Simon Richter <[EMAIL PROTECTED]> writes: > Hi, > >>>As I understand it, the sole purpose of this package is to download >>>non-free firmware. This fits into 'contrib', not 'main', since it >>>depends on non-free software for its ultimate operation. Packages >>>like this are given as an example of packages for contrib. From >>>Policy 2.2.2: > > Hm, that is close to the case of mISDN's "loadfirm" utility. The > consensus back then was that splitting off a (free) firmware loader > from a free package was not worth the effort required (after all, > we're not violating licenses here); also IMO it is a bit > counterproductive, as people wishing to write free firmware would have > to get the firmware loader from contrib then. > > Simon But does it have any use without the non-free firmware? Only then can you close an eye and let it stay in main due to its other functions. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[new version] RFC/RFS: yorick -- interpreted language and scientific graphics
[Note to the debian-science readers: this is a followup to this thread:
http://lists.debian.org/debian-mentors/2006/05/msg00252.html .
All relevant information is included as cited text below.]
Dear all,
I am still looking for a [1] sponsor for [2] Yorick, that I am [3]
adopting.
[1] http://sponsors.debian.net/viewpkg.php?id=282
[2] http://yorick.sourceforge.net/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357679
Yorick has been in Debian for 9 years now, but the former maintainer
(and upstream author) can't take care of the Debian package anymore.
It's a quite viable DFSG-free alternative to [4] IDL. Indeed, I find the
syntax (especially for indexing arrays) quite attractive and I always
use Yorick rather than IDL whenever possible.
[4] http://rsinc.com/idl/
Since my last request, I have split the yorick package into yorick,
yorick-data and yorick-dev . The two add-on packages that I suggest to
review together with Yorick have been updated accordingly
(build-dependency). Please use the following options to
dpkg-buildpackage to ensure the relevant bugs are closed and the
orig.tar.gz is uploaded as well:
yorick(version:2.1.01cvs20060524-2):-v1.5.14-1.1 -sa
yorick-yutils (version: 1.1.1-2): -v0 -sa
yorick-z (version: 1.2.0.0.cvs20060511-2): -v0 -sa
(Note: I did _not_ use -sa when uploading to mentors.debian.net)
The packages are available at
deb-src http://mentors.debian.net/debian unstable main contrib non-free
as well as
deb http://www.mpe.mpg.de/~paumard/debian sid main
deb-src http://www.mpe.mpg.de/~paumard/debian sid main
(sid/i386 binaries only).
The three packages build in pbuilder and are piuparts, lintian and
linda-clean, except for three warnings:
- two lintian Ws have to do with icons that are not found in yorick:
they are in yorick-data;
- the third (found by both lintian and linda) has to do with a command
in the .menu entry that does not belong to yorick. This is on purpose
and works.
Note that most of the debian/ directory is in the orig source. I'm
currently thinking of whether to separate it and how to do that in a
headache-minimising way. (The package was built as "native" up to now).
Thanks for your time and attention,
Best regards, Thibaut.
Le jeudi 25 mai 2006 à 12:43 +0200, Thibaut Paumard a écrit :
> Some more information:
>
> ITA:: #357679
> Package name: yorick
> Version : 2.1.01cvs20060524 (upstream 2.1.02 in development)
> Upstream Author : David H. Munro
> URL : http://yorick.sourceforge.net
> License : BSD
> Description : interpreted language and scientific graphics
> Yorick is an interpreted programming language for:
> * scientific simulations or calculations
> * postprocessing or steering large simulation codes
> * interactive scientific graphics
> * reading, writing, and translating large files of numbers
> .
> The language features a compact syntax for many common array
> operations, so it processes large arrays of numbers very quickly and
> efficiently. Superficially, yorick code resembles C code, but yorick
> variables are never explicitly declared and have a dynamic scoping
> similar to many Lisp dialects. The yorick language is designed to be
> typed interactively at a keyboard, as well as stored in files for
> later use.
> .
> This package includes an emacs-based development environment, which
> you can launch by typing M-x yorick in emacs.
>
>
> The version in the archive (1.5.14) is obsolete (see #333074, 227 day
> old). The former maintainer (who is also the upstream author) has lost
> his upload privileges (lapsed key), so I need a sponsor.
>
> The new version has very interesting new features, in particular the
> ability to load plug-ins. I have completely revamped the package, and
> work with upstream to make Yorick's internal package management system
> integrate well in Debian.
>
> This upload will close 5 bugs (+ the ITA). The two remaining bugs are
> very old, I will close one as "fixed since long" and the other as "won't
> fix" as soon as I become the official maintainer with this upload.
>
> Regards, Thibaut.
In addition, since the new version supports compiled add-ons
("plug-ins"), I have packaged a bunch of these. I recommend reviewing
two add-on packages together with Yorick: one that is a plug-in
(yorick-z), the other one that is a library of interpreted functions
(yorick-yutils). ITPs:
Bug#366710: ITP: yorick-z -- zlib, jpeg, png and mpeg support for the
Yorick language (BSD license)
Bug#366711: ITP: yorick-yutils -- various utilities for the Yorick
language (GPL license)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366710
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366711
More add-ons are available from my repository. They should install
properly, must most will fail to pbuild (dependency on yorick-dev not
marked yet).
--
To UNSUBSCRIBE, email to [EMAI
Re: RFS: serpentine -- An application for creating audio CDs
Le lundi 29 mai 2006 à 12:27 +0200, Sebastien Bacher a écrit : > Le samedi 27 mai 2006 à 22:14 +, Sam Morris a écrit : > > I am searching for a sponsor for serpentine, a GNOME application for > > burning audio CDs. > > Hi, > > There is already an ITP about that package: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286806 > > Julien Valroff <[EMAIL PROTECTED]> mailed me some time ago because he > worked and I accepted to co-maintain the package with him since I > maintain it for Ubuntu already. Did you contact him about the package? He did, and as his packge was much more complete than mine, I let him this package. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Hi, Kevin Bube <[EMAIL PROTECTED]> wrote: > The defoma-hints and scale files are indeed quite tricky. I modified the > scales file by hand as the font itself declares all shapes as medium, so > fontscale duplictes all fonts. I will reread the docs and rework the > defoma-hints. OK. BTW, since the defoma hints file contains the XLFD names of the fonts (those known to X11), I generate the .scale file from the defoma hints file in lmodern, using a sed script run at package build time. Maybe you'd like to do the same. > Do you think the name 'urw-garamond' should be changed at all, since > Ralf pointed out that 'URW Garamond' is not usually connected with > urw garamond No. 8? Maybe the package should be named 'urw-garamond-no8' > then? Yes, after rereading Ralf's comment, I think 'urw-garamond-no8' would be a better name. PS: your forgot to Cc Ralf; he is in the Mail-Followup-To header... Regards, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: serpentine -- An application for creating audio CDs
Le samedi 27 mai 2006 à 22:14 +, Sam Morris a écrit : > I am searching for a sponsor for serpentine, a GNOME application for > burning audio CDs. Hi, There is already an ITP about that package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286806 Julien Valroff <[EMAIL PROTECTED]> mailed me some time ago because he worked and I accepted to co-maintain the package with him since I maintain it for Ubuntu already. Did you contact him about the package? Cheers, Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
Hi, As I understand it, the sole purpose of this package is to download non-free firmware. This fits into 'contrib', not 'main', since it depends on non-free software for its ultimate operation. Packages like this are given as an example of packages for contrib. From Policy 2.2.2: Hm, that is close to the case of mISDN's "loadfirm" utility. The consensus back then was that splitting off a (free) firmware loader from a free package was not worth the effort required (after all, we're not violating licenses here); also IMO it is a bit counterproductive, as people wishing to write free firmware would have to get the firmware loader from contrib then. Simon signature.asc Description: OpenPGP digital signature
Re: RFS: urw-garamond -- scalable PostScript font from the Garamond family
Thanks Florent and Ralf for all your comments. I will try to address your concerns hopefully this week and upload a new version to mentors.debian.net. The defoma-hints and scale files are indeed quite tricky. I modified the scales file by hand as the font itself declares all shapes as medium, so fontscale duplictes all fonts. I will reread the docs and rework the defoma-hints. Do you think the name 'urw-garamond' should be changed at all, since Ralf pointed out that 'URW Garamond' is not usually connected with urw garamond No. 8? Maybe the package should be named 'urw-garamond-no8' then? Regards, Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
