beep-media-player transition options
Hi, We (Audacious package maintainers) would like to provide a transitional package for beep-media-player, since it is now removed in Lenny. We feel that audacious is a sufficient replacement for BMP, as it's BMP's logical successor. BMPx is not a good choice for a transitional package, as it is a different UI and works more like Amarok & friends. Is there any issue with this? William signature.asc Description: This is a digitally signed message part
Re: beep-media-player transition options
On Thu, 2008-01-24 at 09:49 +, Steve Langasek wrote: > On Wed, Jan 23, 2008 at 03:22:46PM -0600, William Pitcock wrote: > > > We (Audacious package maintainers) would like to provide a transitional > > package for beep-media-player, since it is now removed in Lenny. We feel > > that audacious is a sufficient replacement for BMP, as it's BMP's > > logical successor. BMPx is not a good choice for a transitional package, > > as it is a different UI and works more like Amarok & friends. > > > Is there any issue with this? > > Will audacious auto-migrate users' BMP configuration when run? No, but a wrapper (called e.g. beep-media-player) could be provided by the package to do so if such a configuration is present. By providing a wrapper, it allows for people to keep their BMP config seperate from Audacious if they elect to keep BMP around by taking the source package and building it for themselves locally. William signature.asc Description: This is a digitally signed message part
Re: Bug#462740: ITP: demac -- A decoder for Monkey's Audio (APE) lossless files
Hi, demac has some bugs with v3.97 format files. I would recommend merging in patches from ffmpeg and making a seperate product. William signature.asc Description: This is a digitally signed message part
Re: changing the default syslog daemon for lenny?
Hi, On Mon, 2008-01-28 at 01:55 +0100, Michael Biebl wrote: > Joerg Jaspert wrote: > > On 11278 March 1977, Holger Levsen wrote: > > > >> So we decided to switch to syslog-ng for now. > > > >> On the #debian-release channel some people claimed, that syslog-ng is not > >> a > >> drop-in replacement, while other said so. I don't know :) Please explain > >> here. Other options would be rsyslog (which Fedora is using, see > >> http://fedoraproject.org/wiki/Releases/FeatureRsyslog) or msyslog. > > > > It is a dropin replacement with the config that the package delivers in > > Debian. > > rsyslog is also a drop in replacement, even more so, as it can > understand the syntax of sysklogd. The default rsyslog config file > /etc/rsyslog.conf is basically a copy of /etc/syslog.conf. > So if you have a custom syslog.conf, you could either copy it to > /etc/rsyslog.conf or start rsyslogd with -f /etc/syslog.conf. > > rsyslog also allows to include other config files. The default > /etc/rsyslog.conf is setup to include all files in /etc/rsyslog.d/*.conf. > > This easily allows for other packages to add custom configuration very > easily. > > > Of course using syslog-ng means you can take some more advantages > > compared to the old sysklogd - like automated logrotating. > > http://ganneff.de/syslog-ng.conf is an (old) config from me for that, > > which simply keeps logs in a host/year/month/day structure. > > It also has a nice set of filters and stuff, can do tcp and not only > > udp, and lots more. > > rsyslog has all these features, too (and many more). It even offers > support for logging into MySQL and PostgreSQL databases, which only the > commercial syslog-ng branch has. > Support for these is in two separate packages rsyslog-mysql and > rsyslog-pgsql. These two packages use the dbconfig-common framework to > setup the database and automatically create config files for > /etc/rsyslog.d/, so you can get up and running really quick and hassle free. > > A real plus is also upstream, who is very responsive and active and it's > a pleasure to work with him. > > As maintainer of rsyslog, I'd really like to see rsyslog become the > default for lenny and I think it would be a very good choice. > > > Cheers, > Michael I agree with this. Additionally, Balasz Schielder (Balabit) makes people who contribute to syslog-ng sign a contributory license agreement [1], so that they can be included in syslog-ng premium, which is in my view against the whole purpose of open source. If you disagree with signing the CLA, your patch is rejected. As such, I feel that syslog-ng is not a good choice for the default syslogd in Debian. rsyslog upstream have a fairly good reputation of being cooperative and generally good to work with, at least from what i have observed. William [1] http://www.balabit.com/dl/CLA_patch.pdf signature.asc Description: This is a digitally signed message part
Re: Introducing security hardening features for Lenny
On Tue, 2008-01-29 at 22:37 +0100, Pierre Habouzit wrote: > On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote: > > Fortify Source > > == > > > > This feature adds validation for internal C functions such as strcpy > > for buffer sizes known during compile time. While vulnerabilities in > > the functions it protects have become uncommon in high-profile apps, > > it will be useful for fringe packages we have in the archive. > > > > This feature is present in glibc since version 2.5, and is enabled > > through the use of "-D_FORTIFY_SOURCE=2" and "-O2" or higher. > > > > Well, -D_FORTIFY_SOURCE=2 is a severe performance loss in many > applications, and I wouldn't recommend activating it by default. =1 has > not the drawback with that regard though, but is less useful security > wise (though it catch many programmatic issues, and full archive rebuild > with -D_FORTIFY_SOURCE=1 would be worthwile independently of this). > Out of curiosity, what applications in particular does -D_FORTIFY_SOURCE=2 cause issues in? It may be worthwhile to profile this feature and correct it's behaviour if the performance loss is that big of a deal. William signature.asc Description: This is a digitally signed message part
Bug#463167: ITP: dsyslog -- a dumb syslog
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> Hi, I am writing a syslog daemon called dsyslog. Why you ask? Because none of the other syslogd's were designed in the way that I would like, so I figured I would do it myself. * Package name: dsyslog Version : 0.1.0 Upstream Author : William Pitcock <[EMAIL PROTECTED]> * URL : http://nenolod.net/dsyslog * License : ISC (BSD-like) Programming Lang: C Description : a dumb syslog dsyslog is a dumb, yet advanced syslog daemon, which supports infinite rules and expandability through it's purely modular design. The default configuration is a drop in replacement for syslogd. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#463167: ITP: dsyslog -- a dumb syslog
Hi, On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote: > > dsyslog is a dumb, yet advanced syslog daemon, which supports > infinite > > rules and expandability through it's purely modular design. The > default > > configuration is a drop in replacement for syslogd. > > What's so dumb about that? It's not that it's actually dumb, it's like how git is called the "stupid content tracker" by it's documentation. It's intended to be a joke. William signature.asc Description: This is a digitally signed message part
Re: Bug#463167: ITP: dsyslog -- a dumb syslog
Hi, On Wed, 2008-01-30 at 16:22 +1100, Robert Collins wrote: > On Tue, 2008-01-29 at 19:07 -0600, William Pitcock wrote: > > Hi, > > > > On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote: > > > > dsyslog is a dumb, yet advanced syslog daemon, which supports > > > infinite > > > > rules and expandability through it's purely modular design. The > > > default > > > > configuration is a drop in replacement for syslogd. > > > > > > What's so dumb about that? > > > > It's not that it's actually dumb, it's like how git is called the > > "stupid content tracker" by it's documentation. It's intended to be a > > joke. > > Users are very good at missing these jokes. > > -Rob Yes, I hadn't thought of that. I'll just refer to it as a "an advanced and powerful syslog daemon" in the short description then. (on another note, dsyslog is now complete enough that it has replaced the syslogd on my desktop.) William signature.asc Description: This is a digitally signed message part
Re: Bug#463167: ITP: dsyslog -- a dumb syslog
Hi, On Wed, 2008-01-30 at 10:02 +0100, Vincent Bernat wrote: > On Wed, 30 Jan 2008 00:47:45 -0600, William Pitcock > <[EMAIL PROTECTED]> wrote: > > > (on another note, dsyslog is now complete enough that it has replaced > > the syslogd on my desktop.) > > What are the difference with rsyslog which also aims at providing a pure > modular design? > I have heard wonderful things about rsyslog, and I decided to look at it hoping it would be sane. Additionally, the author of rsyslog enjoys hungarian notation (as seen in his code) which after having audited rsyslog is enough to make me not wish to use it (this does not mean rsyslog is bad, it just means I do not like it's design). So I started writing dsyslog, which is free of legacy code and is written in a style which is more agreeable to me. William signature.asc Description: This is a digitally signed message part
Re: Bug#463167: ITP: dsyslog -- a dumb syslog
On Thu, 2008-01-31 at 06:36 +0100, Christian Perrier wrote: > Quoting William Pitcock ([EMAIL PROTECTED]): > > > > Users are very good at missing these jokes. > > > > > > -Rob > > > > Yes, I hadn't thought of that. I'll just refer to it as a "an advanced > > and powerful syslog daemon" in the short description then. > > > Without the leading article, then, please...:-). See DevRef 6.2.2 > Of course. My mistake. signature.asc Description: This is a digitally signed message part
Re: Bug#463862: ITP: ipafont -- Japanese high quality TrueType font
Hi, On Mon, 2008-02-04 at 05:53 +0900, Hideki Yamane wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > >Package name: ipafont This should be ttf-ipafont. William signature.asc Description: This is a digitally signed message part
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Hi, On Sun, 2008-02-03 at 14:19 -0800, Steve Langasek wrote: > On Sun, Feb 03, 2008 at 08:06:22PM +0100, Andreas Tille wrote: > > On Sun, 3 Feb 2008, Kevin Rosenberg wrote: > > >> I think that's contention, the difference in opinion between the > >> package maintainer and some users about what software Debian should > >> provide. > > > Well, if we advise users to compile their stuff on their own > > something is broken. If we can not provide the latest upstream > > version of a certain end user application because we are missing > > some underlying libraries (for whatever reason) we IMHO failed > > in supporting our users. > > I absolutely do not agree that this is a hard rule. If the libraries are > unsupportable, it is a disservice to our users to pretend that we are > supporting them by including them in a release. > > Currently, the packages that are asking for wx2.8 are almost all available > and releasable in earlier versions, built against wx2.6. Uploading wx2.8 to > unstable implies that it's suitable for apps to build against, which by all > accounts it is not. Maybe an upload to experimental would be appropriate then? William signature.asc Description: This is a digitally signed message part
Re: Bug#463973: ITP: deejayd -- A media player daemon
On Mon, 2008-02-04 at 18:08 +0100, Christian Perrier wrote: > Quoting Alexandre Rossi ([EMAIL PROTECTED]): > > Package: wnpp > > Severity: wishlist > > Owner: Alexandre Rossi <[EMAIL PROTECTED]> > > > > > > * Package name: deejayd > > Version : 0.6.2 > > Upstream Author : Mickaël Royer <[EMAIL PROTECTED]> > > * URL : http://mroy31.dyndns.org/~roy/projects/deejayd/ > > * License : GPL > > Programming Lang: Python > > Description : A media player daemon > > I suggest "media player daemon" or "media playing daemon"...but anyway > drop the leading article (DevRef 6.2.2) > > "media player daemon" may be confusing with mpd. "daemon which plays media in the background" may be better. William signature.asc Description: This is a digitally signed message part
Proposal: Alternatives: field for debian/control
Hi, There's a lot of packages in Debian which do the same basic thing, but slightly differently. Having an Alternatives: field would be nice for listing alternative packages which package maintainers may find useful to try if the user does not like how the package they are installing behaves. As for the interface, I think that this would be useful and intuitive: # apt-get install ircd-irc2 .. The following NEW packages will be installed: ircd-irc2 The following packages are alternatives to the packages being installed: inspircd ircd-ircu ircd-hybrid ircd-ratbox This would especially be useful for when people install a virtual package, so that they can get an overview of what other options are available. William signature.asc Description: This is a digitally signed message part
Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions
On Sat, 2008-02-09 at 07:54 +0100, Christian Perrier wrote: > Quoting Jan Hauke Rahm ([EMAIL PROTECTED]): > > Package: wnpp > > Severity: wishlist > > Owner: Jan Hauke Rahm <[EMAIL PROTECTED]> > > > > * Package name: squirrelmail-compatibility > > Version : 2.0.9 > > Upstream Author : Paul Lesniewski <[EMAIL PROTECTED]> > > * URL : http://www.squirrelmail.org/plugin_view.php?id=152 > > * License : GPL > > Programming Lang: PHP > > Description : Squirrelmail plugin used by other plugins to work with > > older SM versions > > I suggest something like "compatibility plugin for old SquirrelMail > versions" > > ...and develop more in the long description, maybe. > > What is the proper capitalization of SM? > SquirrelMail or Squirrelmail? > > Also from reading the documentation of this plugin, it seems some plugins explicitly need version 1.x. As such, shouldn't this be squirrelmail-compatibility2 or something? William signature.asc Description: This is a digitally signed message part
Re: Bug#464766: ITP: squirrelmail-compatibility -- Squirrelmail plugin used by other plugins to work with older SM versions
On Sat, 2008-02-09 at 12:10 +0100, Jan Hauke Rahm wrote: > Can't those plugins use > Depends: squirrelmail-compatibility (<= 2.0) > to solve that? No, because both dpkg and apt generally assume only one version of something is installable at the same time. This is why we have gcc4.2-*, gcc4.3-* etcetera instead of just multiple versions of the same package. On another note: it sure would be nice if dpkg and apt supported the notion of slotting somehow, but I don't expect that to ever happen. As such, you need to distinguish between the different API versions. If they can't co-exist, then use Conflicts: appropriately. William signature.asc Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote: > As far as I can tell, /usr/bin/test and /usr/bin/[ are completely > useless, because none of bash, dash, posh, or zsh use them. Maybe > pdksh > does, but that's pretty much the list of shells that could be coerced > into being /bin/sh. I propose we remove those executables from > coreutils if it turns out that they are never executed. As far as I know, test and [ are infact required to be executables. POSIX says so. I'm .. beyond words right now at this paragraph. signature.asc Description: This is a digitally signed message part
Re: pre-building NEW packages, when they only introduce new binary packages
Hi, On Mon, 2008-02-11 at 18:02 +0900, Charles Plessy wrote: > Le Sun, Feb 10, 2008 at 08:06:38PM +0100, Evgeni Golov a écrit : > > On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote: > > > > > > That probably won't make much time difference on "fast" archs (i386, > > > > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes > > > > hold up testing transition :(). > > > A missing build will only slow testing migration if the package wasn't > > > built when the unstable testing delay is over. Since almost all uploads > > > to NEW are low urgency, the build would need to take over 10 days to > > > affect the time to testing migration. > > > > pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet > > uploaded] today), so it *can* make a difference (not a really big one > > though in this case) > > Indeed, especially that it has been said that having the buildds not > keeping up is not uncommon during a release cycle, implementing a > mechanism to reduce the impact of this problem would be a good thing. > > We are ending up in a similar stress situation as for last release, when > uploading to NEW many weeks before the freeze we were wondering if the > package would be part of the release or not. People with > responsibilities in Debian's core infrastructures should consider that > it is demotivating for many. The main problem is that mipsel is behind at the moment. _THAT_ is demotivating, as it is blocking packages from entering testing which _NEED_ to. Sadly, a port which is probably used by less than 1000 people is blocking needed migrations and even the XMMS removal (!). It'd be nice if mipsel was either given additional resources to stay kept up, or the architecture was disqualfied for Lenny. I'm personally not fussed about which option is chosen. William signature.asc Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
Hi, On Sun, 2008-02-10 at 23:48 -0500, Thomas Bushnell BSG wrote: > On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote: > > So we should also never upgrade /usr/bin/python, /usr/bin/perl, or > > /usr/bin/gcc to point at a new upstream version because users may > have local > > programs that assume particular non-standard behavior from these > programs, > > right? > > I think that's a different case. There is a big difference between a > newer version of the same program and a totally different program with > fewer features. > It's possible for programs to completely change between versions. There really is no difference in reality between switching from program A to program B and switching from program A 1.1 to 1.2. The risk of problems is exactly the same. William signature.asc Description: This is a digitally signed message part
Re: Proposition: 'NMU' upload of wxwidgets 2.8
Hi, On Wed, 2008-02-13 at 00:55 +0100, Vadim Zeitlin wrote: > And, seeing from your signature that you're both a Debian and Ubuntu > developer, I'd like to notice that Ubuntu doesn't seem to find > anything > catastrophic with shipping wx2.8 which it does since quite some time. So Ubuntu ships wx2.8. It doesn't matter to us. The fact that Ubuntu does __ is not generally considered a valid argument for justifying that Debian does the same. Additionally, not all Ubuntu contributors agree with all decisions made in the Ubuntu development process. What you should be telling us is why we _should_ be shipping wx2.8 over wx2.6 which is considered by many to be more proven than wx2.8. I am sure if you can come up with valid reasons to do so (especially identifying critical apps which require wx2.8 features is useful here), that we will be happy to provide wx2.8. William signature.asc Description: This is a digitally signed message part
Bug#466188: ITP: uade -- unix amiga delitracker emulator
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: uade Version : 2.0.9 Upstream Author : Heikki Orsila <[EMAIL PROTECTED]> * URL : http://zakalwe.fi/uade * License : GPL Programming Lang: C, m68k ASM Description : unix amiga delitracker emulator UADE plays old Amiga tunes through UAE emulation and cloned m68k-assembler Eagleplayer API. . UADE contains a free (as in freedom) implementation of Eagleplayer and Delitracker API for UNIX variants such as GNU/Linux (Alpha, AMD64 (x86-64), PA-RISC, PPC, Playstation2 and x86), Free/OpenBSD (x86), Solaris (sparc), Digital Alpha UNIX, IRIX (mips), Mac OS X (ppc), and for other OS variants such as AmigaOS/MorphOS. It is designed to be run as an Audacious input plugin. . A built-in cmdline interface, uade123, also exists. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466187: ITP: ha-audacious -- player for GameBoy Advanced(R) chiptunes
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: ha-audacious Version : 0.41 Upstream Author : William Pitcock <[EMAIL PROTECTED]> * URL : http://nenolod.net/audacious * License : GPL Programming Lang: C, C++ Description : audacious plugin for gameboy advanced chiptunes ha-audacious is a port of the "Highly Advanced" Winamp chiptune plugin to Audacious. It can play GSF and MiniGSF format chiptunes through emulation for the highest amount of possible accuracy. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror CDN had launched.
Hi, On Sun, 2008-02-17 at 13:08 +0100, Vincent Bernat wrote: > 61.115.118.67 is ftp.de.debian.org. I am located in France with an > IP > address of one of the largest ISP here. This ISP is hosting an > official > Debian mirror. 61.115.118.67 is assigned to ASNIC, so there is no possible way it is in Germany. [EMAIL PROTECTED]:~$ host 61.115.118.67 67.118.115.61.in-addr.arpa domain name pointer hanzubin.st.wakwak.ne.jp. I think it is giving you all Japanese servers. William signature.asc Description: This is a digitally signed message part
Intent to hijack gtkglext
Hello, The current maintainer of gtkglext has not been maintaining the package since 2004. The last upload was in 2006 to fix an NMU, which has not been acknowledged yet. The current package is two major versions out of date (1.0 vs 1.2). I need a newer version of gtkglext for various projects I am working on, so if there is no objections within a reasonable amount of time (say a week or so), I intend to prepare an upload and take the package. William signature.asc Description: This is a digitally signed message part
Marcelo E. Magallon seems to be MIA
Hello, Marcelo E. Magallon <[EMAIL PROTECTED]> appears to be MIA, and most of his packages have been NMU'd. You may want to consider orphaning them. I have prepared an upload for gtkglext, so that one can be considered under my maintainership "really soon now". William signature.asc Description: This is a digitally signed message part
Re: Intent to hijack gtkglext
Hi, On Mon, 2008-02-18 at 11:15 +0100, Guus Sliepen wrote: > On Sun, Feb 17, 2008 at 09:20:12PM -0600, William Pitcock wrote: > > > The current maintainer of gtkglext has not been maintaining the package > > since 2004. The last upload was in 2006 to fix an NMU, which has not > > been acknowledged yet. The current package is two major versions out of > > date (1.0 vs 1.2). > > > > I need a newer version of gtkglext for various projects I am working on, > > so if there is no objections within a reasonable amount of time (say a > > week or so), I intend to prepare an upload and take the package. > > If I look at bugs #363395, there have been enough delays already. Just > upload it now. > I've already prepared an upload for this. It should hopefully go sometime today. William signature.asc Description: This is a digitally signed message part
Upstream API breakage question
Hi,
libprojectM upstream are soon releasing libprojectM 1.1 which makes the
following breakage:
public: PCM *projectM::pcm
is replaced by:
public: const inline PCM *projectM::pcm() { return _pcm; }
So, is this the proper solution:
* libprojectm1 -> libprojectm2
* libprojectm-dev -> libprojectm2-dev
* libprojectm-dev becomes virtual package of libprojectm2-dev
If not, what should I do differently?
William
signature.asc
Description: This is a digitally signed message part
Re: Looking for co-maintainer for mercurial
Hi, I'll be happy to help with this package. William On Wed, 2008-02-20 at 19:05 +0100, Vincent Danjean wrote: > Hi, > > I'm the maintainer of the DSCM mercurial. > At this moment, I do not have lot of free time. Moreover, I'm not a > big user of mercurial anymore (I often use git that I find less > intuitive but more powerful). > So I'm looking for co-maintainer of this package. I would be very > disappointed if mercurial is not in a good shape for the next release. > Anyone interested ? (I think the collab-maint alioth project would be > a good place for further development) > > For now, there is 18 opened bugs : > * #415056: mercurial: Install examples systemwide > Package: mercurial (mercurial 0.9.3-2); Reported by: John Goerzen <[EMAIL > PROTECTED]>; Tags: help; 341 days old; Modified 229 days ago. > > I do not find really good work around for this bug (unless until > conditional load of extensions will be implemented in mercurial) > > * #452385: Recording mtime after recording commit message leads to hidden > (lost) changes > Package: mercurial (mercurial 0.9.5-2); Reported by: "Trent W\. Buck" > <[EMAIL PROTECTED]>; 90 days old; Modified 90 days ago. > > Should be reported upstream if not already done by the submitter > > * #462131: hg(1), hgignore(5): incorrect roff code > Package: mercurial (mercurial 0.9.5-3); Reported by: Ivan Shmakov <[EMAIL > PROTECTED]>; 28 days old; Modified 22 days ago. > > Should probably be reassigned to asciidoc (if not already corrected) > > * #465804: mercurial: merge goes belly-up > Package: mercurial (mercurial 0.9.5-3); Reported by: Greg Kochanski <[EMAIL > PROTECTED]>. > * #466003: mercurial: Need better way to close dead branch. > Package: mercurial (mercurial 0.9.5-3); Reported by: Greg Kochanski <[EMAIL > PROTECTED]>. > > Both should probably forwarded upstream > > * #466731: mercurial should depend on python-flup or at less recommends it > Package: mercurial (0.9.5-2~bpo40+1); Reported by: kaouete <[EMAIL > PROTECTED]>. > > New bug (I did not look at it yet). > > * #450645: hg log --style changelog discards branch data > Package: mercurial (mercurial 0.9.5-2); Severity: minor; Reported by: > "Trent W\. Buck" <[EMAIL PROTECTED]>; 103 days old; Modified 103 days ago. > > Need to be investigated (and forwarded upstream ?) > > * #454326: glog: tries to close closed fd > Package: mercurial (mercurial 0.9.5-2); Severity: minor; Reported by: > "Trent W\. Buck" <[EMAIL PROTECTED]>; 77 days old; Modified 77 days ago. > > Need to be forwarded upstream > > * #466006: mercurial: Mercurial merge with meld needs hint > Package: mercurial (mercurial 0.9.5-3); Severity: minor; Reported by: Greg > Kochanski <[EMAIL PROTECTED]>. > > Idem (but hgmerge should disappear in the next upstream version if I > remember correctly) > > Outstanding bugs -- Wishlist items; Will Not Fix (1 bug) > > * #413869: update etch mercurial from 0.9.1 to current version > Package: mercurial (mercurial 0.9.1-1); Severity: wishlist; Reported by: > Aron Griffis <[EMAIL PROTECTED]>; Tags: patch, wontfix; 350 days old; > Modified 113 days ago. > > Just a reminder saying that a backport is available > > > And then, 8 forwarded bugs that need to be followed (there is a time > since I looked at the upstream corresponding bugs) > > Forwarded bugs -- Normal bugs (4 bugs) > > * #427060: mercurial: revert doesn't revert perm changes > Package: mercurial (mercurial 0.9.3-2); Reported by: John Goerzen <[EMAIL > PROTECTED]>; Tags: upstream; Forwarded to > http://www.selenic.com/mercurial/bts/issue816; 264 days old; Modified 109 > days ago. > * #427854: mercurial: hg email doesn't use correct encoding > Package: mercurial (mercurial 0.9.3-2); Reported by: "Wesley J. Landaker" > <[EMAIL PROTECTED]>; Tags: confirmed, moreinfo, upstream; Forwarded to > http://www.selenic.com/mercurial/bts/issue814; 258 days old; Modified 109 > days ago. > * #447088: Problem loading extensions twice (by site and by user) > Package: mercurial (mercurial 0.9.4-1, mercurial 0.9.5-1; fixed: mercurial > 0.9.5-2); Reported by: "Trent W\. Buck" <[EMAIL PROTECTED]>; Forwarded to > http://www.selenic.com/mercurial/bts/issue811; 125 days old; Modified 110 > days ago. > * #447094: hgmerge: uses non-POSIX syntax `type' in /bin/sh script > Package: mercurial (mercurial 0.9.4-1; fixed: mercurial 0.9.5-1); Reported > by: "Trent W\. Buck" <[EMAIL PROTECTED]>; Tags: patch; Forwarded to > http://www.selenic.com/mercurial/bts/issue815; 125 days old; Modified 109 > days ago. > > Forwarded bugs -- Minor bugs (2 bugs) > > * #443428: hgmerge: --help option gives a message that ends strangely > Package: mercurial (mercurial 0.9.4-1; fixed: mercurial 0.9.5-1); Severity: > minor; Reported by: Alexandre Fayolle <[EMAIL PROTECTED]>; Forwarded to > http://www.selenic.com/mercurial/bts/issue817; 152 days old; Modified 109 > days ago. > * #447097: Vacuous e
Re: Looking for co-maintainer for mercurial
Hi, On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: > On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock > > <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I'll be happy to help with this package. > > > > Hi, I'll help with this package too, because I use Mercurial everyday. > > Let's maintain it in: > > > > http://wiki.debian.org/Teams/PythonAppsPackagingTeam > > > > ? > > > > There are many good DD's around the "Python Applications Packaging > > Team" and the "Debian Python Modules Team", because generally, > > this is a Python program, so they may help with many python related issues. > > Any news on this? Do you agree with me importing to package to > Python Applications Packaging Team (PAPT) and changing it's maintainer to > PAPT? > > Ondrej > > I disagree because mercurial is a very specific tool, and needs to be maintained by people who care about mercurial specifically. But if that is what Vincent wants to do, then that's fine. William signature.asc Description: This is a digitally signed message part
Bug#467274: ITP: pcc -- the portable C compiler
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> Hi, I am interested in pcc for several months, so I intend to package it in Debian. * Package name: pcc Version : 0.9.9 Upstream Author : Anders Magnusson <[EMAIL PROTECTED]> * URL : http://pcc.ludd.ltu.se/ * License : BSD Programming Lang: C Description : the portable C compiler pcc is the continuation of the portable C compiler source included in ancient Unix. It has been modernized to support C99 standards and other great features. An advantage to using pcc is that it is stricter about code structure than gcc is. To some extent, it is compatible with gcc CFLAGS, but this is not guaranteed. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
> John H. Robinson, IV writes ("Re: dash bug which is affecting release goal"):
> > Pierre Habouzit wrote:
> > > echo() { /bin/echo "$@" }
> >
> > echo() { /bin/echo ${1+"$@"}; }
> >
> > I believe you mean.
>
> Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+"$@"}, it is ensured that $@ always starts with $1.
What a load of POSIX.
William
signature.asc
Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 08:30 -0600, William Pitcock wrote:
> On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
> > John H. Robinson, IV writes ("Re: dash bug which is affecting release
> > goal"):
> > > Pierre Habouzit wrote:
> > > > echo() { /bin/echo "$@" }
> > >
> > > echo() { /bin/echo ${1+"$@"}; }
> > >
> > > I believe you mean.
> >
> > Why ?!
>
> Because stand-alone $@ is undefined when used in this case. By using ${1
> +"$@"}, it is ensured that $@ always starts with $1.
>
> What a load of POSIX.
>
> William
Oops, I mean "Because the behaviour of stand-alone $@ is undefined".
William
signature.asc
Description: This is a digitally signed message part
Re: Looking for co-maintainer for mercurial
Hi, On Sun, 2008-02-24 at 15:59 +0100, Vincent Danjean wrote: > William Pitcock wrote: > > Hi, > > > > On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: > >> On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > >>> There are many good DD's around the "Python Applications Packaging > >>> Team" and the "Debian Python Modules Team", because generally, > >>> this is a Python program, so they may help with many python related > >>> issues. > >> Any news on this? Do you agree with me importing to package to > >> Python Applications Packaging Team (PAPT) and changing it's maintainer to > >> PAPT? > >> > >> Ondrej > > > > I disagree because mercurial is a very specific tool, and needs to be > > maintained by people who care about mercurial specifically. But if that > > is what Vincent wants to do, then that's fine. > > I'm already in the perl teams and, even if I did not know about the PAPT, I > think it is similar. I mean that I think that even if the package is > maintained > within a team, specific work about one package will be done by the few members > that care about it. > The PAPT will be add value when python transitions occurs or similar 'global' > event in the python world. > > This is why I asked to be added in the PAPT. Piotr Ożarowski just added me > in this alioth project and I plan to upload the current version of mercurial > in the SVN today or tomorrow. > > If it happens that someone willing to work on mercurial packaging (such as > William Pitcock) were denied the access to the PAPT on the ground that they > do not do other python work, I will reconsider my decision and move mercurial > elsewhere (probably in the collab-maint alioth project). But until evidence of > that, I consider that PAPT admins are quite reasonable and that hosting > mercurial > in the PAPT alioth project will add a little more value that in the > collab-maint > project. > And, to answer to a private suggestion, I do not think at all that creating a > specific alioth project for mercurial is interesting : there already exist > several uptream ML to discuss development, an upstream BTS, several upstream > repo, ... So I do not see any benefice to create a new alioth project. PAPT is indeed fine if that's the way you want to go. I'll bounce over to IRC and ask that my account is added. William signature.asc Description: This is a digitally signed message part
Re: Extending fortunes-debian-hints package
Hi, On Tue, 2008-02-26 at 09:39 +0530, Kartik Mistry wrote: > On Tue, Feb 26, 2008 at 12:21 AM, Miriam Ruiz wrote: > > > Feel free to pass it to me for adding your hints into > > > package. > > > > Would it make sense to make a page in the wiki about it? That might > > make it easier for people to add hints :) > > Great idea. Please check: http://wiki.debian.org/FortunesDebianHints > > and get started! I am new to wiki, so improve my formatting too :) > I think it would be nice to have this package as part of the default install, with a hook in .profile to display a hint on login. FreeBSD has a similar feature. William signature.asc Description: This is a digitally signed message part
Re: the new style "mass tirage" of bugs
On Tue, 2008-02-26 at 19:21 +0100, Josselin Mouette wrote: > While bug reports are certainly important input, lame and stupid bug > reports are not. What is lame and stupid to us may not be lame and stupid to the average user. Just because you find no value in a particular report (or set of reports) does not mean that necessarily all of the bug reports submitted by a user are necessarily bad. William signature.asc Description: This is a digitally signed message part
Re: Idea of Debian mascot
On Tue, 2008-02-26 at 12:21 -0600, Gunnar Wolf wrote: > In natural environments, you could hardly find animals living as far > apart as polar bears and penguins. A polar bear has to swim/walk close > to 15,000Km (as neither lives really on the poles, right?) to find a > decent penguin. "to find a decent penguin"? Could you clarify what you mean by "decent" here? (Also, it's a bloody mascot, who cares if they don't /really/ live in the same locations. They live in the same /climate/ and that's good enough for most people.) William signature.asc Description: This is a digitally signed message part
Re: Idea of Debian mascot
On Tue, 2008-02-26 at 21:19 +0100, Harald Braumann wrote: > On Tue, 26 Feb 2008 14:45:05 +0100 > "Miriam Ruiz" <[EMAIL PROTECTED]> wrote: > > > 2008/2/26, David Given <[EMAIL PROTECTED]>: > > > Lars Wirzenius wrote: > > > > > > > I'd really rather see something nicer than an ant as a mascot. :) > > > > > > How about a cockroach? Beautifully engineered, indestructable, and > > > they're *everywhere*... > > > > No thanks, I preferred the Weasel idea to this :P > > And why does it have to be an animal at all? I for one can't identify > with any specimen of the *nix bestiary. Except maybe with the bsd > daemon, but that's technically not a beast. But all those foxes, > chameleons, penguins and what not -- I don't know. If an animal at all, > I would definitely prefer a cockroach. But it's maybe hard to > manufacture from plush. What about a tarantula? Fluffy by design. > I don't really see why you couldn't make a stuffed Debian swirl. I'd buy one of those. Maybe we could call the Debian swirl our mascot and come up with some lame name like "Swirly the Debian mascot". It could be like that talking paper clip they always make fun of in M$ Office. Hmm! Maybe a "Debian assistant"... "*boing* I see you are trying to install a package, do you want help with that?" William signature.asc Description: This is a digitally signed message part
Re: the new style "mass tirage" of bugs
On Wed, 2008-02-27 at 10:20 +0100, Josselin Mouette wrote: > You don’t know Jidanni, do you? It doesn't matter if I do or not. Someone who is trying to contribute shouldn't be told to piss off, or ridiculed on -devel. Doing that will drive away not only that contributor, but any potential contributors that are friends with them. William signature.asc Description: This is a digitally signed message part
Re: Looking for co-maintainer for mercurial
Hi, On Wed, 2008-02-27 at 08:11 -0600, John Goerzen wrote: > On Tue February 26 2008 6:55:53 am Ondrej Certik wrote: > > On Tue, Feb 26, 2008 at 1:20 AM, Edward Allcutt <[EMAIL PROTECTED]> > wrote: > > > > > > So that would make hg the only VCS package maintained in a VCS inferior > > > to itself? :P > > > > That's because hg-buildpackage is not really used much in Debian and > > also it seems noone is interested in it much, see also this bug or > > rather a wish: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448444 > > > > that I reported 4 months ago with no response at all. > > It is a valid point that you can reconstruct the upstream branch just from > the tags. But Mercurial in-tree branches are not at all the same as Git > in-tree branches, and don't really lend themselves to this sort of > development process as easily. In Mercurial, you are really encouraged to > have the separate branches as separate dirs on disk. I think there are a > few things that hg-buildpackage does which git-buildpackage doesn't yet, but > nothing significant. > > I simply hadn't had the chance to think about that deeply yet. > > But I am now in the process of moving my Debian packaging work from Mercurial > to Debian. If you, or someone else, would like to take over > hg-buildpackage, please contact me. > Taking over hg-buildpackage seems interesting to me. William signature.asc Description: This is a digitally signed message part
Re: apt-get and SOCKS!
On Thu, 2008-02-28 at 16:53 +, Jon Dowland wrote: > On Thu, Feb 28, 2008 at 11:39:06AM +0100, Edward Tjornhammar wrote: > > apt-get provides http_proxy and ftp_proxy support but why not SOCKS? > > I have no experience with SOCKS other than that I use it daily in > > conjunction with firefox and ssh. I think it is a feature which could > > be of use to others as well since it would enable you to use apt over > > ssh. > > I'd suggest checking for a wishlist bug filed against apt, > requesting SOCKS support. If it doesn't exist, file it. At least with curl, 'export http_proxy="socks5://ip:port/"'. So it might work with apt too. I've used apt with a socks proxy before, I know that. William signature.asc Description: This is a digitally signed message part
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
On Thu, 2008-02-28 at 18:47 -0600, Gunnar Wolf wrote: > Guus Sliepen dijo [Wed, Feb 27, 2008 at 07:55:08PM +0100]: > > > Monkey is a Web Server written in C based on the HTTP/1.1 protocol. The > > > objective is to develop a fast, efficient, small and easy to configure > > > webserver. > > > Although it is very small and does not need much system resources, it > > > has a lot of nice features like Multithreading, Mimetype Support, > > > Virtualhosts, CGI & PHP, Basic Security features (Deny by URL + IP) > > > > The language the server is written in is not important. Use the debtags > > system to annotate the package with that kind of information. Also, > > don't use subjective wording like "nice features". There are also too > > much capitals in your description. I suggest the following: > > > > Monkey is a small, fast, and easily configurable HTTP/1.1 compliant web > > server. It uses multi-threading and has support for MIME, virtual > > hosts, CGI and PHP. It offers basic security features, such as denying > > access to certain URLs for certain IP addresses. > > Even there, it looks very much like other "very small" webservers, > such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, > mini-httpd or thttpd. What does it do better than any of them? Or > worse? Or different? Why does a package need to clarify what's different about it than others like it? Debian is about having the possibility of choosing between many options for the same thing e.g. openssh, dropbear for sshd, 12 different httpd options, etc. Package descriptions should stick to positive aspects of the package, and not try to draw comparisons towards other packages. IMO. It seems to me as if you are trying to get people to justify the packages they want to work on. If that is the case, then, I think "because the person wants to use _this_ package" is fine. Infact, I would go as far as saying that the wide latitude of software options for a specific task is one of the greatest strengths of Debian. As such, I think the revised description is perfectly acceptable for Debian. William signature.asc Description: This is a digitally signed message part
Re: Many packaged programs that are doing the same thing
Hi, On Fri, 2008-02-29 at 10:38 +0100, Guus Sliepen wrote: > On Thu, Feb 28, 2008 at 08:02:39PM -0600, William Pitcock wrote: > > > > Even there, it looks very much like other "very small" webservers, > > > such as boa, bozohttpd, cherokee, fnord, lighttpd, micro-httpd, > > > mini-httpd or thttpd. What does it do better than any of them? Or > > > worse? Or different? > > > > Why does a package need to clarify what's different about it than others > > like it? Debian is about having the possibility of choosing between many > > options for the same thing e.g. openssh, dropbear for sshd, 12 different > > httpd options, etc. > > There is nothing wrong with having multiple packages in Debian that do > the same thing. However, you can wonder whether it is really helpful for > the user to have 10 or more light-weight http daemons to choose from. As > a distribution, we have a much broader view than the authors of those > http daemons. When we see something like this, maybe we should contact > the upstream authors and suggest that they work together, so that the > number of light-weight daemons to choose from decreases but the quality > of the remaining will be better. > > Again, I'm not saying there should only be one light-weight http daemon. > But more than 10? > Why not? Debian ships more than 10 different shells, media players, etc. Why should an httpd be not included because there are already others. This isn't about being "helpful", this is about _choice_. Have you considered that perhaps the upstreams don't work together because they DON'T WANT TO? Again, it's a matter of _choice_. As a distribution, Debian's goals are to: * provide the widest latitude of free software; * provide the highest quality of packaging of said free software; * ensure the software we ship by default is really free. If that means having a lot of different httpds to choose from, then great! You're not being forced to use them, so why does it matter to you if they are available in Debian? Most software in Debian is maintained for personal reasons, e.g. the maintainer uses it. What further justification than that is required? William signature.asc Description: This is a digitally signed message part
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Hi, On Fri, 2008-02-29 at 11:16 +0100, Thijs Kinkhorst wrote: > On Fri, February 29, 2008 03:02, William Pitcock wrote: > > Why does a package need to clarify what's different about it than others > > like it? Debian is about having the possibility of choosing between many > > options for the same thing e.g. openssh, dropbear for sshd, 12 different > > httpd options, etc. > > The word "different" is key here. Debian wants to offer different options > to its end users. But please, only options that are significantly > different to what we already have. > There are several costs associated with having yet another package doing > the same thing: > * For the project in general, it costs archive and Packages file space, > build time, QA efforts just to name a few; > * Especially true for network facing services: the security team needs to > support every package in stable; > * For the administrator: having a choice between a few webservers is good, > having to choose between a dozen that are hardly different just troubles > their view. You can have too much choice. Clearly these packages are different enough to somebody if they are going to the effort of packaging them. Perhaps they have a superior configuration format or some other non-notable feature. But if you are worried about the QA and security team, then why not create an unsupported repo. It could even be a good solution towards recruiting new DDs. Lets call it, say, 'community', 'extras', or 'unsupported'. The main featureset I see here would be: * Anyone could register with it, and upload their packages. There would be buildd's and whatnot, so for all purposes, it would be similar to having packages in Debian proper. * If the package is good, it could be migrated into Debian proper where it would receive proper security team and QA attention. * It would allow people who are having problems finding mentors to upload on their behalf the ability to still contribute to Debian's package collection. Which in turn, would probably eventually lead them towards a mentor. * It would give end users the ability to learn more about DAK and all of the other stuff involved in Debian packaging in a hands-on environment. * It would allow a greater latitude of options while not adding additional workload on the QA and security teams. * Community QA'd, meaning a hands-on learning experience for those who might be interested in joining the QA team. * As it is not an official Debian repo, but instead a community repo, Debian ftp maintainers would choose for themselves whether or not to mirror it, like backports.org. If the project is successful, it could later be offered as an option at install time to get more packages. > > We can obviously live with the costs that a package incurs, but it makes > sense only if there is something that offsets the cost: a clear added > value of this package to the distribution. That is something that must be > able to be justified when any new package is added. "Just because" doesn't > cut it. > Sure in the Debian main repo, but if a community repo existed, it would not matter. > > Package descriptions should stick to positive aspects of the package, > > and not try to draw comparisons towards other packages. IMO. > > A package description is intended for the administrator to choose which of > a set of alternatives to install. A comparison to others, or being open > about possible limitations, are very helpful to make this decision. Use debtags for that. > > > It seems to me as if you are trying to get people to justify the > > packages they want to work on. > > Yes, and that's very desirable. Telling people to go away because you don't want to QA their package is not desirable at all. William signature.asc Description: This is a digitally signed message part
Re: Bug#468183: ITP: monkey -- small webserver based on the HTTP/1.1 protocol
Hi, On Fri, 2008-02-29 at 10:33 -0600, Gunnar Wolf wrote: > But the user should not have to install 10 small HTTP servers just to > know what's the goddamn difference. That's extremely unhelpful from > us. We should tell the prospective user at a first glance why he wants > one httpd over another. I agree that this reasoning is fine. Sorry if I misjudged your intent. William signature.asc Description: This is a digitally signed message part
Re: Unsupported?
Hi, On Fri, 2008-02-29 at 21:54 +0900, Paul Wise wrote: > unsupported.d.n could be the right place for packages that are "not > good enough for Debian (yet)". It could be a good place to merge > packages removed from Debian for having no users (or whatever), > uploaded to Ubuntu, Nexenta, Preventa, mentors, revu and any other > Debian-based distros that have public archives. A while ago on -devel > there was a post about automatic creation of rough packages using > automatic software discovery and AI techniques for the packaging, such > packages could be uploaded to unsupported. Upstreams often make Debian > packages but don't upload them anywhere, unsupported could be a place > for them. I've often wanted to package some cool software (see the > list on my wiki page), but not maintain it forever, so I didn't bother > and just moved on. Instead I could just upload to unsupported. As I see it, unsupported would be: * packages excluded from main for whatever reason (think: GTK1, XMMS), * packages not yet "good enough" for main (or not yet sponsored, uploading to mentors could automatically put built packages in unsupported, for example.), * packages that someone made, but does not want to maintain, * community maintained (e.g. you could bump the version by uploading to mentors, or uploading directly to unsupported if you are a DD/DM), * and most importantly _UNSUPPORTED_. That said, provided that it's clear that it's _UNSUPPORTED_, it could become an additional asset for Debian users. The community maintainance concept has proven to be quite reasonable, other projects have had great success with this sort of thing, think ArchLinux's AUR, Gentoo's "Sunrise" Overlay, etcetera. Yes, some person can upload an evil package, but with proper moderation, evil packages can be dealt with in a timely manner. Did I mention that it is unsupported? William signature.asc Description: This is a digitally signed message part
Re: Unsupported?
Hi, On Fri, 2008-02-29 at 09:57 -0800, Steve Langasek wrote: > So if it's unsupported, set it up yourself instead of asking Debian to > dedicate resources to it. > I wasn't aware that I was asking Debian to dedicate resources to it. William signature.asc Description: This is a digitally signed message part
Re: Please allow the migration of the packages stalled in the MIPS buildd backlog.
Because they don't want to. William On Sun, 2008-03-02 at 17:30 -0500, Michael Casadevall wrote: > What about simply decoupling mips/mipsel's version numbers so an out of > date package on mips(el) doesn't stall out the rest of the testing. Having > (somewhat) setup britney/update_out to generate testing for m68k, it > should just be a matter of adding of adding mips and mipsels, to the > proper lists in update_out.py. As it stand armel uses this (hence why in > update_excuses it says Ignoring armel dependency). > > As I haven't fully gotten britney running, there could obviously be a big > problem, but it might be a fessible way to allow mips/mipsel to have > testing, and not break everyone else. > Michael > > On Sun, 2 Mar 2008, Lucas Nussbaum wrote: > > > Date: Sun, 2 Mar 2008 18:57:03 +0100 > > From: Lucas Nussbaum <[EMAIL PROTECTED]> > > To: debian-devel@lists.debian.org > > Subject: Re: Please allow the migration of the packages stalled in the MIPS > > buildd backlog. > > Resent-Date: Sun, 2 Mar 2008 19:26:18 + (UTC) > > Resent-From: debian-devel@lists.debian.org > > > > On 02/03/08 at 23:34 +0900, Charles Plessy wrote: > >> I have not asked MIPS to be removed from the list of released > >> architectures. I have asked testing migration to be uncoupled from MIPS > >> building while the buildds are suffering. In a previous thread it has > >> been suggested that this operation requires a minimal amount of work. > > > > It requires a minimal amount of work to remove mips from the > > architectures considered for testing transitions. On the other hand, it > > requires a lot of work if we still want to release with mips after that, > > because from that point, testing and testing-mips will start diverging. > > Getting them back in sync will be really hard, and actually, it's likely > > to cause us to release without mips. > > > > So, even if it would be better to have testing be in good state, it's > > not a release blocker yet, and developers should concentrate on fixing > > bugs. Users can use testing + apt pinning. I use that on all my !stable > > systems. > > -- > > | Lucas Nussbaum > > | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | > > | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Sun, 2008-03-09 at 19:27 +, Faidon Liambotis wrote: > You're hurting the credibility of the comittee and of the whole > project. > That's much more important than a disagreement on a technical matter. On the other hand allowing dpkg to be maintained in the way that it presently is, is also hurting the credibility of the whole project. NOT THAT I AGREE WITH THE HIJACKING. That too, is not the proper solution to this. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote: > And what is the problem exactly? The delay in patch integration? A six month delay is unacceptable for code review. If it takes six months, then new leadership is clearly required. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Sun, 2008-03-09 at 13:19 -0800, Mike Bird wrote: > including the triggers enhancement which is > needed for boot time improvements and which should simplify some other > packaging issues. I think you mean package install-time improvements, due to postponing ldconfig until the end of the installation. However, I am not sure how useful this is because many maintainer scripts not generated by debhelper call ldconfig locally. Obviously the maintainer scripts autogenerated by debhelper would be ok though. William signature.asc Description: This is a digitally signed message part
Bug#470574: installs into non-policy-compliant /usr/libexec
Package: mingw32 Version: 4.2.1.dfsg-1 Severity: serious Justification: policy 8.2 (?) Hi, After installing mingw32, I noticed the following files in /usr/libexec/gcc, they should be installed to /usr/lib/gcc instead: /usr/libexec /usr/libexec/gcc /usr/libexec/gcc/i586-mingw32msvc /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/mkheaders /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/fixincl /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/install-tools/fixinc.sh /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1 /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/cc1plus /usr/libexec/gcc/i586-mingw32msvc/4.2.1-sjlj/collect2 At least in my opinion; if I am wrong then please let me know and close the bug. William -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mingw32 depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii mingw32-binutils 2.18.50-20080109-1 Minimalist GNU win32 (cross) binut ii mingw32-runtime 3.13-1 Minimalist GNU win32 (cross) runti mingw32 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi,
On Tue, 2008-03-11 at 22:06 -0700, Mike Bird wrote:
> Hi Guillem,
>
> Ian wrote that you recently committed 402 diff lines of stuff
> like this:
> -static void usage(void) {
> +void
> +usage(void)
> +{
>
> It's easy to see negatives such as making it harder to merge
> long-awaited features. What positives do you see for Debian?
The horse is dead. Stop beating it.
William
signature.asc
Description: This is a digitally signed message part
Re: Intend to hijack xchat-xsys
Hi, On Tue, 2008-03-11 at 22:19 -0200, UlisesVitulli wrote: > I've been talking with the maintainer[1] of xchat-xsys[2] for several > bugs and many new upstream releases hold back on Debian, and he > communicated me that he is not longer interested on maintaining it any > more. Tell him to orphan the package, then. Alternatively, but more controversially, you might consider orphaning it yourself, and CC'ing the maintainer. But that's controversial, and I wouldn't recommend it unless you can back up your claims. William signature.asc Description: This is a digitally signed message part
Re: dpkg semi-hijack - an announcement (also, triggers)
Hi, On Wed, 2008-03-12 at 11:16 -0700, Mike Bird wrote: > Ian appears to have chosen to speak truth to power rather than > forking. Do you have a constructive alternative to suggest? $ echo ":/dpkg/i" >> ~/.killfile William signature.asc Description: This is a digitally signed message part
Re: Proposing a new source control header to link to upstream BTSs
On Mon, 2008-03-17 at 02:38 -0300, Martín Ferrari wrote: > Dear -devel: > > Following the trend to add metadata to the debian/control file that > allows for the creation of new and powerful tools, I thought about the > usefulness of a header that'd allow to automatically relate to > upstream bug trackers. > > It could be used to automatically forward bugs, track which bugs are > open that we don't know about today, and simply to avoid the need to > look up manually where should one submit a bug. > > So, my proposal would be to add two headers that are better explained > by an example: > > Upstream-Bug-Browser: > http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl > Upstream-Bug-Submitter: > http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl > > This could easily support systems where submission is by email. And if > there's no bug tracking system, the upstream maintainer email could be > used, without adding the -Browser header. > > What do you think of this? > I don't see what purpose this has that Homepage: does not, because it is not likely that there will ever be an automated reporting tool. It is just more metadata, and as such, is generally wasteful since it doesn't usually provide anything that Homepage: does not. William signature.asc Description: This is a digitally signed message part
Bug#471726: ITP: mpx -- library-oriented media player
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: mpx Version : 0.0 Upstream Author : Milosz Derezynski <[EMAIL PROTECTED]> * URL : http://hg.backtrace.info/mpx * License : GPL Programming Lang: C++ Description : library-oriented media player MPX is a media player which provides a very easy-to-use interface and usage semantics for all tasks, while having extensive standards and services support under the hood (MusicBrainz, Last.fm radio/scrobbling, HAL, DBus), yet keeping the details out of the way of the user. . MPX is a media player that features support for specifications like XDS DnD, XSPF and DBus. MPX is highly interoperable and integrates well with other applications and a variety of desktop environments. MPX guys are writing a successor to MPX now called mpx. I intend to package it once it becomes usable. So, the same long description as MPX will mostly apply here, as it's basically the same idea, but with newer code. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BitTorrent and ISP interference (was: What CDs and DVDs should we produce for lenny?)
Hi, On Thu, 2008-03-20 at 07:51 +1100, Ben Finney wrote: > That is a problem that won't be solved by avoiding use of BitTorrent; > on the contrary, reducing legitimate use of BitTorrent can only result > in supporting those who would paint BitTorrent as a tool without > significant legitimate use. This has nothing to do with "legitimate" or not "legitmate" use; this has to do with the fact that BitTorrent and swarm-based P2P networks in general overload many ISPs infrastructure since ISPs like to highly oversell their networks. Putting pressure on them will not do any good, and infact, someone who claims that it has to do with piracy will look like an idiot in 90% of cases where BitTorrent is blocked. William signature.asc Description: This is a digitally signed message part
Re: Bug#471726: ITP: mpx -- library-oriented media player
Hi, On Thu, 2008-03-20 at 07:39 +0100, Yves-Alexis Perez wrote: > On mer, 2008-03-19 at 14:17 -0500, William Pitcock wrote: > > MPX guys are writing a successor to MPX now called mpx > > You mean BMPx? Yes, yes I do. William signature.asc Description: This is a digitally signed message part
Re: RFC: preventing accidental deletion of system directories
Hi, On Sat, 2008-03-22 at 22:16 +1300, Francois Marier wrote: > Basically, the wrapper (see attached file) has a blacklist which > contains > directories like /usr/lib, /home, /etc and removes those before > passing its > arguments to the real 'rm' command. While I'm sorry for you having to reinstall your system, I think that having such a wrapper as a default feature in Debian is absolutely ludicrous and should be avoided at all costs. Maybe asking "Are you sure you want to do this", but outright refusing to do something seems quite ridiculous to me. Also, what you would do is dpkg-divert /bin/rm, and then call /bin/rm.coreutils or whatever. William signature.asc Description: This is a digitally signed message part
Re: RFC: preventing accidental deletion of system directories
Hi, On Sat, 2008-03-22 at 13:51 +0100, Adam Borowski wrote: > To get those Vistaesque questions, "alias rm='rm -i'" is surely not > worth a > package. It's slightly larger in scope, but only slightly, as > removing > files as root means you mess with system directories, right? Yes, that's what I mean: what's wrong with making rm -i the default behaviour? We could do that by simply patching coreutils. William signature.asc Description: This is a digitally signed message part
Re: RFC: preventing accidental deletion of system directories
Hi, On Sun, 2008-03-23 at 00:08 +, Steve McIntyre wrote: > Christ, no. If you want Fedora you know where to find it. I was being sarcastic. But it's certaintly better than making some script the default. Optimally no change to rm is best unless you opt in. William signature.asc Description: This is a digitally signed message part
Re: Bug#474016: ITP: desktop-data-model -- a library for Mugshot and Online-Desktop
Hi, On Wed, 2008-04-02 at 15:15 -0500, Ron Johnson wrote: > That doesn't appear to be a valid address, It redirects to > http://www.mugshot.com/ which seems to be just a bunch of links to > scam and valid commercial web sites. Mugshot has always been at mugshot.org; not mugshot.com. So the ITP creator should take note of this. http://developer.mugshot.org/ is a mediawiki instance :) William signature.asc Description: This is a digitally signed message part
Re: Should -dev packages providing .pc files depend on pkg-config?
Hi, On Sat, 2008-04-05 at 15:30 +, brian m. carlson wrote: > I think it is safe to say that Debian supports passing the > appropriate > command line arguments without using pkg-config, even if upstream > does > not. At least that seems to be my experience. Yes, but people depending on this point will find that their code does not work correctly on non-Debian platforms, which is most likely a disservice to our users in reality. William signature.asc Description: This is a digitally signed message part
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Hi, On Mon, 2008-04-07 at 19:57 +0200, Peter Jordan wrote: > Hi, > > why are the keyrings of debian-multimedia.org and debian backports not > in the official repository of debian? > > At the moment you have to install untrusted keyrings before you can use > these repositories. Because they are third party repositories and not affiliated in any official way with the Debian project. William signature.asc Description: This is a digitally signed message part
Bug#477106: ITP: codecgraph -- generate a routing graph for an Intel-HDA codec
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: codecgraph Version : 20080406 Upstream Author : Eduardo Habkost <[EMAIL PROTECTED]> * URL : http://helllabs.org/codecgraph/ * License : GPLv2 Programming Lang: Python Description : generate a routing graph for an Intel-HDA codec codecgraph is a utility used to generate an SVG graph of an HDA codec's routing paths. It is useful for debugging audio problems relating to Intel-HDA codecs. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479440: ITP: funpidgin -- A pidgin fork
Hi, On Sun, 2008-05-04 at 23:28 +0100, Ben Hutchings wrote: > On Sun, 2008-05-04 at 23:24 +0300, Mohammed Sameer wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Mohammed Sameer <[EMAIL PROTECTED]> > > > > * Package name: funpidgin > > Version : 2.4.1 > > Upstream Author : A lot. Can't be listed here! > > * URL : http://funpidgin.sourceforge.net > > * License : GPL > > Programming Lang: C > > Description : graphical multi-protocol instant messaging client based > > on pidgin > > > > Funpidgin is a graphical, modular Instant Messaging client capable of using > > AIM/ICQ, Yahoo!, MSN, IRC, Jabber, Napster, Zephyr, Gadu-Gadu, Bonjour, > > Groupwise, Sametime, SILC, and SIMPLE all at once. > > It has all the features offered by pidgin plus: > > * "Entry area manual sizing" a plugin by that allows manual resizing of the > > entry area. > > * An option to set the size of the buddy icons displayed in the chat window. > > * An option to let the window manager place new windows. > > * Two different ways of seeing that your buddies are typing. > > * An optional send button for Tablet PC users. > > Maybe you could wait to see whether this fork lasts, and adds some > *substantial* features, before adding it? > I too have concern that this fork will not last, but they are receptive to my ideas and patches, so perhaps I have motivation to make sure the fork is successful. William signature.asc Description: This is a digitally signed message part
Re: Bug#479440: ITP: funpidgin -- A pidgin fork
Hi, On Mon, 2008-05-05 at 09:10 +0200, Joachim Breitner wrote: > Hi, > > Am Montag, den 05.05.2008, 01:19 -0400 schrieb Kevin Mark: > > On Sun, May 04, 2008 at 11:28:40PM +0100, Ben Hutchings wrote: > > > On Sun, 2008-05-04 at 23:24 +0300, Mohammed Sameer wrote: > > > > Package: wnpp > > > > Severity: wishlist > > > > Owner: Mohammed Sameer <[EMAIL PROTECTED]> > > > > > > > > * Package name: funpidgin > > > > Version : 2.4.1 > > > > Upstream Author : A lot. Can't be listed here! > > > > * URL : http://funpidgin.sourceforge.net > > > > * License : GPL > > > > Programming Lang: C > > > > Description : graphical multi-protocol instant messaging client > > > > based on pidgin > > > > > > > > Funpidgin is a graphical, modular Instant Messaging client capable of > > > > using > > > > AIM/ICQ, Yahoo!, MSN, IRC, Jabber, Napster, Zephyr, Gadu-Gadu, Bonjour, > > > > Groupwise, Sametime, SILC, and SIMPLE all at once. > > > > It has all the features offered by pidgin plus: > > > > * "Entry area manual sizing" a plugin by that allows manual resizing of > > > > the entry area. > > > > * An option to set the size of the buddy icons displayed in the chat > > > > window. > > > > * An option to let the window manager place new windows. > > > > * Two different ways of seeing that your buddies are typing. > > > > * An optional send button for Tablet PC users. > > > > > > Maybe you could wait to see whether this fork lasts, and adds some > > > *substantial* features, before adding it? > > > > > > Ben. > > > > > > > my understanding is that this is a 'protest' fork made to add a feature > > that the upstream did not want(the resizing). So as long as the upstream > > resists, it should survive. > > Could we, as the Debian distribution, not make the decision what variant > we want to distribute? We can take the useful patches from funpidgin, if > they are good, and add them to “our” pidgin. That might be the best for > our users and in the spirit of free software, although it might be bad > for our relationship with upstream pidgin. > Pidgin and Funpidgin are clearly two different projects, although not much rebranding has yet happened. While this seems like a good solution, it is likely not: * some users will likely prefer Pidgin as it is over Funpidgin; * Funpidgin has features (MSN P14/Pecan support) that cannot easily be integrated into Pidgin without ugly patchsets. A solution, provided that the public plugin API isn't changed in Funpidgin could be to install pidgin-plugins to a shared location, and patch both clients to load plugins from that directory as well as their native locations. > In any case I suggest that the maintainers of pidgin and funpidgin try > to work together to keep the packages in debian compatible as possible, > e.g. when it comes to plugins and the like. > Having talked with upstream (and now joined upstream), funpidgin is becoming more of a refactoring project of pidgin's code, as well as readding features which were removed. As such, while funpidgin will likely try to maintain the public interface, there will be reasons to run funpidgin over pidgin and vice-versa. In my view, funpidgin will probably be more valuable to the Debian user community than pidgin (even with patching) due to planned improvement of i18n-related issues (character set transcoding, etcetera) and an overall improved and refactored codebase. William signature.asc Description: This is a digitally signed message part
Bug#480509: ITP: mudkip-player -- an XMMS replacement
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: mudkip-player Version : 1.0~pre1-hg20080510 Upstream Author : William Pitcock <[EMAIL PROTECTED]> * URL : http://www.nenolod.net/mudkip-player (pending) * License : GPL Programming Lang: C Description : an XMMS replacement Mudkip-player is a combination of the Audacious 1.5 and BMPx (old XMMS-like version) codebases. It behaves like XMMS and includes a few useful enhancements. Mudkip is based on GStreamer and is not compatible with XMMS plugins, but includes select features from both BMPx and Audacious. -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
Hi, On Tue, 2008-05-20 at 17:21 -0300, Luciano Bello wrote: > Hi list, > I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to > manage a hard meticulous QA process in all packages. In the other hand, there > are packages more critical than others, which are more delicate to security. > Sometimes, those packages have different priorities in the policy > meaning. > Maybe we can implement this as an Optional header in the control. > The point is: if we can create critical QA category for delicate > packages in > the security sense we can have mandatory QA requirement. For example: > - It should be checked with debugging tools (like valgrind :P) Isn't valgrind how we got into this mess to begin with? > - It should maintained by a team > - It should a public VCS > - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) > proposed something like this) > > You can extend or reduce this list. We can discuss about the > implementation. > But I mainly want to know your opinion. > Please, paste the URL if you discussed this in the pass. > > luciano I think for critical packages, valgrind prettyness isn't something to care about (unless the interest is generating suppressions). William signature.asc Description: This is a digitally signed message part
Re: Bug#482414: ITP: guake -- A drop-down terminal for Gnome Desktop Environment
Hi, On Thu, 2008-05-22 at 21:39 +0200, Yves-Alexis Perez wrote: > Hmh, what are the real differences with tilda? AFAIK, tilda does not use VTE for it's terminal emulation, Guake does. William signature.asc Description: This is a digitally signed message part
Bug#483899: ITP: sockstat -- clone of freebsd's sockstat(1) utility
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: sockstat Version : 0.1 Upstream Author : William Pitcock <[EMAIL PROTECTED]> * URL : http://www.nenolod.net/sockstat * License : BSD Programming Lang: C Description : clone of freebsd's sockstat(1) utility This package is a clone of freebsd's sockstat(1) utility. It includes features like the ability to search for open sockets by user, program-specific socket usage information, searching for listening sockets, connected sockets, and much more. -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485553: ITP: charybdis -- fast, scalable irc server
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: charybdis Version : 3.0.1 Upstream Author : William Pitcock <[EMAIL PROTECTED]>, Jilles Tjoelker <[EMAIL PROTECTED]>, Valery Yatsko <[EMAIL PROTECTED]>, Michael Tharp <[EMAIL PROTECTED]> * URL : http://www.ircd-charybdis.net * License : GPL Programming Lang: C Description : fast, scalable irc server Charybdis is a fast, scalable IRC server, capable of supporting tens of thousands of connections. It supports SSL and X.509 certificate challenge-response authentication. Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody seems to care about that, I'm going to assume that it's OK. -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
Hi, On Tue, 2008-06-10 at 11:21 +0200, Guus Sliepen wrote: > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote: > > > * URL : http://www.ircd-charybdis.net > > * License : GPL > > > > Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody > > seems to care about that, I'm going to assume that it's OK. > > People DO care, and it is not OK. Linking with OpenSSL is only allowed > if there is an exemption to the license of charybdis that explicitly > allows linking to the OpenSSL. See for example this page which gives a > nice summary and links to some related debian-legal emails: It is likely impossible to add an exemption to most IRCd notable exceptions include ngircd or inspircd, because some of the original "ircd 2.8" contibutors are now dead. Due to packet interception and logging, SSL support in IRC daemons is becoming a hot topic. Without OpenSSL, packaging charybdis is pointless for me, as the whole idea of packaging it would be to make it easier to install on my systems. And without OpenSSL, it isn't easier for me to install because I would have to rebuild the package with OpenSSL. So, in a nutshell, nobody in the current IRCd development community cares about perceived GPL+OpenSSL compatibility issues, so only Debian does, which is "ok", but that's not so useful when Debian is already shipping packages linked against OpenSSL with no exception (see below). Here's some packages which are linked against OpenSSL and should not be (this is not an all exhaustive list, you should grep-dctrl on a Sources or something): - epic4 (impossible to get an exception, dead contributors) - inspircd would but I chose not to build that module because they ship a gnutls one instead (charybdis is basically stuck with openssl due to using libcrypto directly) - oftc-hybrid (impossible to get an exception, dead contributors) - openvpn (may or may not have exception, more checking needed) - xchat (might be possible to get an exception, but author doesn't care about GPL anyway, see also: Shareware XChat for win32) - znc (status unknown, but i see no exception in the source) So, in the grand scheme of things, I don't really think one more package linked against OpenSSL is going to hurt anything. If it makes you happy, I could bolt an exception on the code, but I doubt it would hold water due to the fact that there are dead copyright holders. But at the moment, porting to GnuTLS is really not an option, as I would have to port to GCrypt too for the cert exchange, and that couldn't be easily done with libgnutls-extra. I suppose using libgnutls-extra and not supporting X.509 cert auth for gaining admin access is an acceptable compromise provided that libgnutls-extra implements enough of the OpenSSL API. William signature.asc Description: This is a digitally signed message part
Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
On Tue, 2008-06-10 at 10:46 -0700, Steve Langasek wrote: > > - oftc-hybrid (impossible to get an exception, dead contributors) > > * As a special exception, the authors give permission to link the > code of this > * release of oftc-hybrid with the OpenSSL project's "OpenSSL" > library (or > * with modified versions of it that use the same license as the > "OpenSSL" > * library), and distribute the linked executables. You must obey > the GNU > * General Public License in all respects for all of the code used > other than > * "OpenSSL". If you modify the code, you may extend this exception > to your > * version of the files, but you are not obligated to do so. If you > do not > * wish to do so, delete this exception statement from your version. You've been conned. OFTC-Hybrid is based on Hybrid which is based on 2.8 and therefore cannot add such an exception; it is effectively in the same boat that charybdis is in. I could lie and add the same exception to my debian/copyright too, but it wouldn't be true and it wouldn't be right to do so. Furthermore, a grep of that string in the source brings no results other than debian/copyright, which demonstrates that nothing actually HAS this exception anyway: [EMAIL PROTECTED]:~/oftc-hybrid-1.6.3.dfsg$ grep "As a special exception, the authors give permission" * -R debian/copyright: * As a special exception, the authors give permission to link the code of this [EMAIL PROTECTED]:~/oftc-hybrid-1.6.3.dfsg$ At any rate, I intend to wait until version 3.1 of charybdis anyway now, which has a GNUTLS backend (I've written it, and it just needs to be debugged). William signature.asc Description: This is a digitally signed message part
Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
Hi, On Tue, 2008-06-10 at 15:04 -0400, Joey Hess wrote: > William Pitcock wrote: > > - znc (status unknown, but i see no exception in the source) > > Wow, you had me thinking I was a copyright fool for a minute there > (and wondering how such a mistake got past the ftpmasters), > until I took a look at znc's debian/copyright and LICENSE.OpenSSL: > > In addition, as a special exception, the copyright holders give > permission to link the code of portions of this program with the > OpenSSL library under certain conditions as described in each > individual source file, and distribute linked combinations > including the two. > [...] > That list was, among other things, based on comments made by upstream authors about usage of OpenSSL and this problem. I'm glad to hear that psychon has changed his mind though. I've filed bugs on the actual packages that don't hold water, now. William signature.asc Description: This is a digitally signed message part
Re: Bug#485553: ITP: charybdis -- fast, scalable irc server
Hi, On Tue, 2008-06-10 at 21:18 +0200, Robert Millan wrote: > On Tue, Jun 10, 2008 at 11:50:47AM +0200, Miriam Ruiz wrote: > > 2008/6/10 Guus Sliepen <[EMAIL PROTECTED]>: > > > On Mon, Jun 09, 2008 at 11:43:53PM -0500, William Pitcock wrote: > > > > > >> * URL : http://www.ircd-charybdis.net > > >> * License : GPL > > >> > > >> Like oftc-hybrid, I intend to link this to OpenSSL. Since nobody > > >> seems to care about that, I'm going to assume that it's OK. > > > > > > People DO care, and it is not OK. Linking with OpenSSL is only allowed > > > if there is an exemption to the license of charybdis that explicitly > > > allows linking to the OpenSSL. See for example this page which gives a > > > nice summary and links to some related debian-legal emails: > > > > > > http://www.gnome.org/~markmc/openssl-and-the-gpl.html > > > > I don't know if it's possible, but you might want to try to link it to > > GNUTLS [1] instead. > > GNUTLS has an OpenSSL portability layer, but it is not complete. It would > require some porting work. > > Btw, the build system in ircd-charybdis considers OpenSSL an optional > dependency. If it's an optional feature, why not just disable it untill a > better solution is found? Because SSL is a requirement for my requirements. I wish to replace inspircd with something that is more suited for my requirements (e.g. something I can use CGI:IRC with, without having ban-evasion issues). We've already found a temporary solution (although I certaintly don't like the side effect that it makes the daemon binary GPLv3), which is to use the portability layer until a native backend for GNUTLS is written (and just simply not have the certificate-based opering feature until it's properly abstracted -- right now it's dependent on libcrypto availability). Obviously a native GNUTLS backend is the best solution, but releasing charybdis 3.0.2 with an openssl.c that can build against gnutls-extra is fine for the immediate future. William signature.asc Description: This is a digitally signed message part
Bug#485703: ITP: libratbox -- portable runtime for ircd-ratbox and charybdis
Package: wnpp Severity: wishlist Owner: William Pitcock <[EMAIL PROTECTED]> * Package name: libratbox Version : 3.0.0~svn25529 Upstream Author : Aaron Sethman <[EMAIL PROTECTED]>, Jilles Tjoelker <[EMAIL PROTECTED]> * URL : http://www.ircd-ratbox.org/ * License : GPL Programming Lang: C Description : portable runtime for ircd-ratbox and charybdis Libratbox is the portable runtime used by ircd-ratbox and ircd-charybdis. It features an abstractable design allowing for SSL support and high performance I/O. . In Debian, SSL support is provided by GNUTLS and should be considered experimental at the moment. Support may be added to allow for local users to rebuild using OpenSSL if desired instead of GNUTLS. This is still being considered; the official Debian version will always use GNUTLS. -- System Information: Debian Release: lenny/sid Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-free IETF RFC/I-Ds in,source packages
Hi, On Mon, 2008-06-16 at 11:18 +1000, Brian May wrote: > I tried to upload what I have so far to Debian experimental so that > others can look at it (I hate being the sole maintainer of such a > complicated package). I think this is within the scope of experimental, > for anything that is experimental and might be broken. In this case it > breaks policy by not being DFSG compliant. Unfortunately it got rejected > with the message I should use non-free instead. > > I am wondering if the ftp-masters missed the point that it is an > existing package already in main and should not get moved to non-free. > Unfortunately this was an issue because one of the sonames for one of > the shared libraries was also incremented, resulting in the package > being marked as new. There are alternative places where you can upload your packages that don't have the requirements for acceptance into Debian proper. I do not believe that experimental is the appropriate place for packages to be reviewed, but instead is a place for packages to be uploaded where the technology is not yet seen as stable enough to go into Debian unstable in the mind of the maintainer. For example, you could upload your packages to mentors.debian.net if all you want to do is have people examine your source package. With tools like dget, all you have to do is just upload your package anywhere and pass a URL to the .dsc file. William signature.asc Description: This is a digitally signed message part
Re: Bug#486429: ITP: eternallands-music -- the music package for Eternal Lands, a free MMORPG
On Mon, 2008-06-16 at 02:15 +0100, Paul Broadhead wrote: > Package: wnpp > Severity: wishlist > Owner: Paul Broadhead <[EMAIL PROTECTED]> > > > * Package name: eternallands-music > Version : 1.6.0 > Upstream Author : Radu Privantu and Maura Privantu > * URL : http://www.eternal-lands.com > * License : (Free to distribute) This doesn't seem free to me, the license says: "3. You are NOT allowed to take our art (2d/3d files), and use it for your own devious purpose, either commercial or not. The only exception is if you want to make some sort of fan website, in which case it is OK to use some of our art on that site. Of course, taking a screenshot and using it for whatever you need is perfectly OK. Just don't use our art for your own game/software. If you really want to do that, then send me an e-mail, with information on where/how/what/why you want to use, and, most likely, we can come to a deal." Which really doesn't seem to meet Debian's definition of free. But maybe I am wrong? The same license applies for eternallands-data, obviously. As far as the game itself goes, this one is a real showstopper: "4. If you want to [re]distribute this game, you are NOT allowed to modify anything. You can, however, distribute some txt/doc/etc file, with information about you, etc." You can read the license of this MMORPG here: http://www.eternal-lands.com/page/license.txt Also, this license seems dubious at best. William signature.asc Description: This is a digitally signed message part
Considerations for lilo removal
Hi, I am wondering if it is a good idea to remove lilo entirely. At the moment, lilo has been pulled from testing, and the code is in a shape where a grave bug (bug #479607) is unlikely fixable without severe refactoring of the codebase. With grub being stable and grub2 approaching stability itself, do we really need lilo anymore? It's not even installed by default anymore, and the only systems I have that are still on lilo are installations of Debian I have had since Woody. It seems like moving to grub for everything may be a good choice on the archs where lilo is used. If we do not need lilo, then I will file a RM bug in the next couple of weeks. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 09:08 +0200, Romain Beauxis wrote: > Le Monday 16 June 2008 07:31:49 William Pitcock, vous avez écrit : > > With grub being stable and grub2 approaching stability itself, do we > > really need lilo anymore? It's not even installed by default anymore, > > and the only systems I have that are still on lilo are installations of > > Debian I have had since Woody. > > I have lilo for the systems where I want /boot to be on LVM. > What would you do for those installs ? > That doesn't strike me as a valid configuration. Infact, it shouldn't work with lilo because lilo wants /boot to be on a real device. The fact that it does should be considered a bug, not a feature. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 07:20 +, Sune Vuorela wrote: > On 2008-06-16, William Pitcock <[EMAIL PROTECTED]> wrote: > > That doesn't strike me as a valid configuration. Infact, it shouldn't > > work with lilo because lilo wants /boot to be on a real device. The fact > > that it does should be considered a bug, not a feature. > > lilo-22.8$ head debian/patches/01_devmapper.dpatch > #! /bin/sh -e > ## > ## All lines beginning with `## DP:' are a description of the patch. > ## DP: Patch to make lilo understand device-mapper block devices. > ## DP: Bug#229932 > That patch only makes lilo map LVMs to an appropriate physical device. It does not guarantee that you will be able to boot off of an LV on a physical volume. As such, the behaviour is still undefined. Consider a situation where /boot spans multiple PVs, and you will see lilo fail to boot the system correctly. If /boot happens to be on a single PV, then it will work, but it is still not guaranteed. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 19:27 +1000, Alexander Zangerl wrote: > please don't remove lilo. It certaintly won't be happening in lenny. This may be revisited in lenny+1 though. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 00:31 -0500, William Pitcock wrote: > [a lot of stuff] As many people have brought up usecases not covered by alternatives, the plan seems to be: * Cope with the growing initramfs issue as best we can, e.g. by displaying a warning to the user that the kernel may not be bootable by lilo due to the 8MiB boundry in liloconfig. An upload is already prepared to do exactly this, and is pending a merge with some translation updates which have not all been received yet. At that point, an upload will hit incoming and a fixed lilo will hit Debian in time for Lenny's freeze (whenever that may be). On another note, if you want to improve the translations for lilo in Lenny, you have 4 days to get them into the upload that will be made. * Possibly revisit this issue if this outcome is not enough for Lenny+1. We will probably be revisiting this issue because working around bugs is not really the greatest way of handling them. By then, it is hopeful that grub or grub2 can be adapted to handle any missing features not provided already. Thank you all for your feedback, it has been helpful for determining how to handle the situation. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
Hi, On Mon, 2008-06-16 at 13:58 -0700, Mike Bird wrote: > FWIW, adding "-9" to the gzip in mkinitramfs gives a > 0.5% saving, which may help with some marginal cases. > > OTOH using bzip2 instead of gzip saves 10.5% but I have > no idea how much work it would take to support bzip'd > initrd's. > > --Mike Bird > > Ultimately the issue is that initramfs-tools now uses MODULES="most" instead of MODULES="dep". In the pending upload, liloconfig will advise changing the config file for initramfs-tools to restore the old behaviour to create an initrd which will fit in the 8MiB boundary. I suspect the reason why nobody considered this to be a problem is because Grub is already running in 32bit mode by the time the kernel is loaded and booted. But I could be wrong. After all, I don't speak for the initramfs-tools developers. William signature.asc Description: This is a digitally signed message part
Re: Considerations for lilo removal
On Mon, 2008-06-16 at 23:53 +0200, Frans Pop wrote: > William Pitcock wrote: > > * Cope with the growing initramfs issue as best we can, e.g. by > > displaying a warning to the user that the kernel may not be bootable by > > lilo due to the 8MiB boundry in liloconfig. > > Having only a warning is not sufficient for the use of lilo in new > installations! We really need lilo to fail there, which means a non-zero > exit code. My warning is followed by exit(-1), actually. William signature.asc Description: This is a digitally signed message part
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi, On Mon, 2008-06-23 at 19:34 +0200, Francesco Poli wrote: > I *used* to think that those disclaimers are implicit in most cases. > > But then, I was harshly accused of not making it clear enough that > I am neither a lawyer, nor a Debian developer, that I'm not providing > legal advice, and that I don't speak on behalf of the Debian Project. > Other people were similarly attacked for the same reason. > > http://lists.debian.org/debian-legal/2006/10/msg00133.html > http://lists.debian.org/debian-legal/2007/06/msg00014.html > http://lists.debian.org/debian-legal/2007/06/msg00038.html > http://lists.debian.org/debian-legal/2007/06/msg00092.html > http://lists.debian.org/debian-legal/2007/06/msg00106.html > http://lists.debian.org/debian-legal/2007/06/msg00222.html > http://lists.debian.org/debian-legal/2007/06/msg00278.html > http://lists.debian.org/debian-legal/2007/07/msg00062.html > http://lists.debian.org/debian-legal/2007/07/msg00215.html > > As a consequence I began adding the disclaimers to my messages, in > order to explicitly remind readers about the above facts. > > Now, you say that those disclaimers are a waste of time... > > I'm really puzzled. > Have you ever heard the fable concerning a father, a son and a donkey? In a nutshell, first, nobody rides down the road on the donkey, and instead lead him with a rope. People criticized them for doing so, e.g. "why not let the kid ride on top of the donkey?" So, the father told the kid to ride the donkey. Then people criticized them again, for not letting the father ride the donkey instead. So, they switched again. Then people criticized that too, so they wound up carrying the donkey. Eventually, they reached a stream and fell in the water because there was too much weight in once place on the bridge they were crossing. The moral of the story is that no matter what you do or say, somebody will complain about it. So, the best path to take is the one which you think is correct. Judging by the point that you used to believe that the disclaimers were implicit, it seems like going back to assuming that might be a good idea. But, that's just my opinion, obviously. William signature.asc Description: This is a digitally signed message part
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 2008-06-29 at 19:12 +1200, Chris Bannister wrote: > On Mon, Jun 23, 2008 at 12:49:50PM -0500, William Pitcock wrote: > > Have you ever heard the fable concerning a father, a son and a donkey? > > In a nutshell, first, nobody rides down the road on the donkey, and > > instead lead him with a rope. People criticized them for doing so, e.g. > > "why not let the kid ride on top of the donkey?" > > > > So, the father told the kid to ride the donkey. Then people criticized > > them again, for not letting the father ride the donkey instead. So, they > > switched again. Then people criticized that too, so they wound up > > carrying the donkey. Eventually, they reached a stream and fell in the > > water because there was too much weight in once place on the bridge they > > were crossing. > > Wouldn't that happen whether they were riding or carrying the donkey? Mathematically, probably. But this is just a fable, so the laws of physics obviously don't apply completely here. William signature.asc Description: This is a digitally signed message part
Re: gnome, kde, xfce use non-policy main menu
Hi, On Sat, 2008-07-05 at 02:42 -0400, Daniel Dickinson wrote: > For discussion: > > Gnome, KDE, and XFCE are the the top three desktops used in debian and > cover most users of desktops in debian. > > They all use xdg .desktop-based menus as their main menu. > > xdg .desktop-based menus are not covered by policy. Honestly, policy really needs to be updated to use the XDG standards menu spec, and every WM at this point really should be using them for their menus. I think the debian-menu system should be seen as legacy, since it has been replaced with a standard used and supported by many upstreams and many other distros. However, there's a few places where debian-menu is a better solution though. (It can be used to build menus for many WMs which do not support XDG, but honestly, do we need all these WMs?) Another solution would be to make debian-menu build .desktop entries for the menu in the main menu namespace and not the 'Debian' namespace; this seems like the easiest solution. William signature.asc Description: This is a digitally signed message part
Re: gnome, kde, xfce use non-policy main menu
Hi, On Sat, 2008-07-05 at 01:46 -0700, Russ Allbery wrote: > You mean the specification that is followed mostly in the breech by actual > implementations and to which KDE at least has a whole ton of extensions? > I think the XDG standard is actually *based* on the Desktop Entry spec from KDE1/KDE2, but this is only based on vague memories of writing .desktop/.icon files back in 1999-2003. So, it doesn't surprise me that KDE implements more than the spec. But I haven't used KDE3 much, so I don't know if it's still the way it was last time I touched KDE, which was in the Debian 2.2/3.0 days... Or maybe the Desktop Entry spec is based on the minimal ground seen between both KDE and GNOME, in which case, it's sad that it hasn't improved since that point... William signature.asc Description: This is a digitally signed message part
Re: Considerations for 'xmms' removal from Debian
José Miguel Parrella Romero gmail.com> writes: > > The maintainers of the xmms package in Debian are proposing the removal > of the aforementioned package. Please read on. > > 1. Rationale > > * Upstream has deprecated development and support for the current > version of XMMS. > * Several parts of the application are broken and no longer of Debian > quality. > > 2. Current status > > * The BTS reports 231 bugs, most tagged 'important' or 'normal', and a > couple of debugging was attempted with little success. > * XMMS is broken in several aspects, one of the most important being > it's dependence on GTK+ 1.2 and no UTF-8 support, which is standard in > Debian Etch. > * Other distributions have already discussed XMMS removal. Gentoo > hardmasked the package based on the same rationale [1] Yes, and Gentoo's user committee fucked over the entire image and public view of Audacious' direction. Gentoo's (mis)handling of PR during this transitional time has resulted in a lot of negativity towards audacious and several lame attempts to find security holes in Audacious with the explicit purpose of trying to get XMMS back. I strongly suggest this doesn't happen in Debian, as upstream may not like the result otherwise. The general consensus of our team is that we're not going through this nightmare again. > * 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon. > Both are very good and development-active substitutes to xmms. At present, the only completely successful mainstream xmms->audacious to date has been in Slackware, but that's because Pat didn't lie to the users about our goals and project direction. Please respect our project and make sure it happens this way in Debian if you provide an xmms->audacious upgrade path. > * There's also in Debian the upstream-supported xmms2 package, 2598 in > popcon rank. > > 2.1 Reverse depends > > The following packages depend on XMMS: > Most of this packages are xmms plugins. Maintainers will need to port > them to xmms2 or bmpx, or they should be removed. > A large majority of these plugins have been ported to Audacious already. > Other packages just depend on xmms as a mere multimedia player, and > therefore we recommend the maintainers to adjust their dependencies to > bmpx, xmms2 or audacious. > That's fine as long as you respect our requests with regards to handling the PR of this. > 2.2 Popcon > > xmms is now 1069 in the overall popcon rank, with 11029 installations, > not counting the plugin users. > > Yours, > the XMMS maintainers > > [1] http://www.gentoo.org/proj/en/desktop/sound/xmms.xml > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Andreas Tille rki.de> writes: > > On Sun, 8 Jul 2007, Thomas Viehmann wrote: > > > Removing the package from Debian will not affect current users that > > much, > > While I perfectly agree that there are replacements for xmms that at > first view look like a new version (for instnce audacious) many user > might have links form their desktops or other hooks that just call > /usr/bin/xmms. So this might affect a lot of users and especially > those users that have no idea how to cope with a missing xmms in their > PATH. IMHO the only way to fix this is to provide a transitional > package that for instance depends from audacious (or other clones), > provides xmms and conflict with older xmms versions and install a > symlink to the replacement. > We are not an XMMS clone. Would you like us to remove the Winamp2 UI to drive this point further? If this nonsense keeps happening, it's exactly what we will be doing. Architecturally, Audacious is much different than XMMS, it just sorta looks like XMMS, which I think sends the wrong message, but whatever. The fact is that we do not consider ourselves to be an XMMS clone or an XMMS replacement, and you should strongly consider that before removing XMMS and providing a transitive upgrade path to audacious. I'm not asking much, just some sort of notification telling users that the "replacement" they are installing is not really a replacement to XMMS, and as such some "features" are implemented in a drastically different way. Thanks, William > I think xmms is to wide spread as that we just could wild guess how > many users are affected and how they could cope with this. Somebody will just maintain their own repo with gtk1.2 and xmms if it's required. This already happens in gentoo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Steve Greenland moregruel.net> writes: > > Like it or not, your software fits very much into the role played > by XMMS, such that someone who likes XMMS is more likely to choose > Audacious than, say, Rythymbox. That's why it's being discussed as a > "replacement". If we remove XMMS from the distribution, we have some > obligation to point users at similar tools. > > Since you obviously modeled Audacious on XMMS (via BMP), I'm not sure > why you find such comparisons offensive. > > Steve Because every time distros try to do an xmms->audacious migration on us, it causes additional load on our development effort because people file bug reports and demand that we behave exactly like XMMS. I don't find the comparison offensive, I find the result of the comparison offensive, which is people dictating to us how our project will work. I cannot work efficiently under those conditions, and I don't suspect anyone else could either. So, it becomes a PR nightmare for us. That's why I take offense and ask for very strong clarification that we are not cloning XMMS to the letter. That's what "XMMS clone" means to these people. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Jon Dowland alcopop.org> writes: > Unless I've got my timeframes wrong, there were a few > successful attempts too. What's objectionable about people > trying to find security flaws in your software, apart from > their motivation for doing so? > There is nothing wrong with trying to find security flaws. However, there have been no security flaws found in audacious itself, but instead in the third party code we carry on. We have infact used these flaws to motivate distributions to keep the latest audacious always available to their userbase, e.g. "hey 1.2.2 has a ton of flaws, you might want to upgrade it in your next release if you weren't doing so already." My issue is that I find it patently offensive that people attack my work simply because they wish to regain XMMS in their distribution. Maybe I am wrong in thinking that way, but I'm pretty sure I'm not. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal speakeasy.net> writes: > It's my impression that audicious is not scriptable so it can't be > as easily integrated into existing applications or controlled from emacs > or irssi. [EMAIL PROTECTED] ~ $ audtool current-song New Order - The Rest Of - Age of Consent [EMAIL PROTECTED] ~ $ audtool current-song-filename file:///home/nenolod/03%20Age%20of%20Consent.mp3 [EMAIL PROTECTED] ~ $ audtool current-song-length 5:13 (demonstrations of the other commands not done because there's a lot of them) Seems pretty scriptable to me. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Josselin Mouette debian.org> writes: > > Whether you like it or not, audacious is a playlist-based audio player > with support for many audio formats and funny plugins. This description > sounds much like XMMS, which is why it can be considered a good > replacement. As a user, I don't care about the architecture being > different (apart from the bugs gone away). > The only thing I ask for is that you don't assert that Audacious is a 100% identical "XMMS clone". Saying that Audacious is a suitable replacement is fine, saying that we are an "XMMS clone" in any official documentation will likely result in users harassing us. Which we don't want. After all, would you if you were in our position? Gentoo did this initially and we got hit with an onslaught of unhappy migrants. My position is to make sure that does not happen again. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal speakeasy.net> writes: > > There are a number of plugins available from the rarewares repository[1] and > perhaps other third party repositories which provide the only convient way > I'm aware of to access a number of media formats (bonk, wavepack, lossless > audio, shorten, various DVD audio formats). While I do not expect debian to > support these packages, I do ask that the wider ecosystem be taken into > consideration. > Audacious supports wavpack out of the box. I have an unofficial port of bonk and shorten on my computer which I can package on request; and there was at one time a port of xmms-ac3dec to Audacious, but it doesn't work with the new plugin API. At any rate, the ecosystem for Audacious is pretty much the same as it is for XMMS. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Lionel Elie Mamane mamane.lu> writes: > > Would a mention of the "different direction of audacious" in the > release notes of lenny, the next Debian release, fulfil your "PR > handling" request? Something like Simply not asserting that Audacious is a fullstop "XMMS clone" will fulfill my request. > > 4.5 XMMS removal > > Due to concerns over its high number of bugs, unmaintained status > (and hence bugs will not get fixed), usage of old, unmaintained > libraries (gtk+ 1.2) and no UTF-8 support, xmms has been removed from > Debian. We suggest users of xmms try 'bmpx' and/or 'audacious' for > media players that may feel familiar to them. You may also want to > give xmms2 a shot: it is by the same upstream than xmms, albeit feels > very different. > The developers of bmpx no longer have a player that is anything like Audacious or XMMS. It uses GStreamer and looks more like Amarok than XMMS. You should look at their Screenshots[1] before recommending it as an XMMS replacement. I'm not qualified to comment on XMMS2. Sure, audacious is similar to XMMS, and claiming that is fine. Claiming that we are an XMMS *clone* sends the wrong message to your user base and causes problems in upstream with bugreports like: (a) Feature X is broken in Audacious because it's not like XMMS. (b) You don't _. That's a regression from XMMS. (c) Why doesn't Audacious have _? XMMS does. As long as we don't hear about 'regressions from XMMS' as a result of a migration path provided by Debian, then you have fulfilled my request. This is where Gentoo initially failed to succeed in their migration. William [1] http://beep-media-player.org/site/Screenshots -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Don Armstrong debian.org> writes: > Like it or not, bug reports are a part of software development that we > all have to deal with. Suggesting announcements or text for such a > transition may help, but at the end of the day distributions are going > to switch as projects mature or decay. Complaining about the > transition occuring isn't going to resolve your concern. If you think I am complaining about debian transitioning from xmms to audacious, I am not. I like bug reports /that have merit/. Simple comparisons to XMMS do not provide such merit. I am complaining about developer time being wasted by xmms zealots which will likely harass us on our tracker. > Users shouldn't be able to dictate to you how the project works; they > don't do the development. In Debian's case, refer these users to our > bug tracking system (as all of our documentation refers users.) Then debian will resolve their complaints locally using patches, which means we will likely have to adopt the position of not providing any upstream support to debian. I would like to avoid that, but if debian patches audacious to make it work like XMMS, then we would have no choice but to reject bugs reported to us using the debian patched binaries. As an example, what Debian ships as 'xmms' is quite different than what you normally get in the CVS of XMMS. I would like to see that not happen to audacious. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
Steve Langasek debian.org> writes: > > I wonder why audacious and audacious-plugins should be separate packages at > all instead of building them into a single binary package, given that this > circular dependency relationship exists (even if not on paper currently). > Because we (audacious) release the player and the plugins seperately. This allows for faster QA procedures to happen during the development workflow, as we don't have to freeze development of both the player and the plugins, we can just concentrate on one or the other. For instance, the latest audacious player is 1.3.2, and the latest plugins pack is 1.3.5. William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
