Re: Packages still depending on GTK+ 1.2
On Sunday 07 December 2008 16:10:34 Charles Plessy wrote: > With its thousands of packages, Debian is not so rich in manpower, so if > the current maintainers of GTK+ 1.2 want to abandon it and the QA team is > not interested in keeping it, there is no other choice than to adopt it > (and its 43 bugs) if you want it to stay in Debian. It had less than upload > per year since 2003, so maybe it is doable. Also, I think that it is > possible to opt-out security support if this an issue (but it might make > the package unfit for release). I must admit I was under the impression from this discussion that GTK+ 1.2 was simply _unwanted_ in Debian due to reasons of out-of-dateness and possible security problems... I am quite willing to adopt the package and maintain it, but I couldn't find it on the list of orphans. Maybe I didn't look hard enough? That list is enormous... :-( On a side note, I already am attempting to adopt a companion for GTK+ 1.2, namely gktglarea [1]. The modified package is on mentors and I am looking for a sponsor [2] (nudge nudge :-)) > In our experience with GAMGI (http://www.gamgi.org/), GTK+ 1.2 was indeed > useful to prepare a preliminary package that helped to convince Upstream to > GTK 2.0. Good point! But as an illustration to my point, let me quote from a forum message by the GAMGI author before he decided to make the transition. His statements are representative of the problems of many scientific programmers, who typically distribute their programs themselves: > I am the first author of GAMGI (http://www.gamgi.org/), which depends on > Mesa, Expat, Freetype 2, Glib 1, Gtk 1, Gtkglarea1, that's why I am so keen > about compiling these libraries myself. > > Glib 1, Gtk 1 and Gtkglarea1 are considered obsolete and becoming more and > more difficult to get from Linux distributions (by the way, GtkGlarea 2 is > an old library that works with Gtk 2.*, not Gtk 1.2.10, replaced by > Gtkglext, the new way to bridge Gtk 2.* and Mesa code) and until I change > to Gtk 2 or 3 (which is not trivial, as Gamgi has now in excess of 200,000 > lines of C code), I need to get them to work, not just to me but to my > users as well. Currently I am distributing these pre-compiled libraries > (.so and .h files) for x86, xf86_64 and ppc architectures, but to feel in > control I need to be able to compile these libraries myself, as I always > did in the past. I usually have several different versions of mesa, expat, > etc. installed simultaneously, for testing purposes, etc. Cheers, Morten [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471986 [2] http://tinyurl.com/6f7f57 -- Morten Kjeldgaard, asc. professor, MSc, PhD BiRC - Bioinformatics Research Center, Aarhus University C. F. Møllers Alle, Building 1110, DK-8000 Aarhus C, Denmark. Lab +45 8942 3130 * Fax +45 8942 3077 * Home +45 8618 8180 Mobile +45 5186 0147 * http://www.bioxray.au.dk/~mok -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Le lundi 08 décembre 2008 à 14:35 +0100, Morten Kjeldgaard a écrit : > I must admit I was under the impression from this discussion that GTK+ > 1.2 was > simply _unwanted_ in Debian due to reasons of out-of-dateness and possible > security problems... Yes, it is unwanted. I’d like to see it entirely disappear before GTK+ 3.0 (which should be out in a year or so if the schedule is kept) lands in the archive. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Packages still depending on GTK+ 1.2
On Sat, 2008-12-06 at 19:08 +0100, Josselin Mouette wrote: > Le vendredi 05 décembre 2008 à 21:43 -0600, Raphael Geissert a écrit : > > > Alain Schroeder <[EMAIL PROTECTED]> > > >gsnes9x > > > => visualboyadvance ? > > > > C'mon, there are at least 15 years between the two consoles. > > And nope, visualboyadvance doesn't replace gsnes9x, although the latter is > > just > > a front-end. > > Gah, I thought it was able to handle SNES ROMs. The correct answer would > probably be zsnes, although it only works on i386. > Actually, gsnes9x can just be dropped. It is just a frontend to snes9x (which, afaik, uses Xlib directly). William signature.asc Description: This is a digitally signed message part
Re: Packages still depending on GTK+ 1.2
On Sat, 2008-12-06 at 20:42 +0100, Klaus Ethgen wrote: > You forgot xmms. It is still heavily used and there are no alternative > for it. (It is just such a application as xv - very old but there are no > alternative that completely replace it (in all facets).) There's not? There's at least 20 different media players in Debian that are available, that cover the same codec support (at least partially) of XMMS. Unless you're talking about the ugly XMMS GUI. In which case, I believe QMMS is available for packaging. William signature.asc Description: This is a digitally signed message part
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard wrote: I am quite willing to adopt the package and maintain it, but I couldn't find it on the list of orphans. Maybe I didn't look hard enough? That list is enormous... :-( On a side note, I already am attempting to adopt a companion for GTK+ 1.2, namely gktglarea [1]. The modified package is on mentors and I am looking for a sponsor [2] (nudge nudge :-)) Morten, Maybe I've already offended you but I already offered to sponsor your gtkglarea upload, I just had a question on the soname mismatch that I asked about on -mentors. Thanks, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
BTS usertag with an userid that is not an email address.
Hi all, I am doing some pilot tagging to implement my idea of peer review for the `debian/copyright' file. Since I have no plan of setting and managing a contact email for this, I tried to define a usertag with a username that is not an email address: aqwa『~』$ bts user copyright-peer-review . usertag 505251 requested Unfortunately, it did not work: - Forwarded message from Debian Bug Tracking System - Date: Mon, 08 Dec 2008 14:33:06 + Subject: Processed (with 2 errors): user copyright-peer-review, usertagging 505251 Processing commands for [EMAIL PROTECTED]: > user copyright-peer-review Selected user id (copyright-peer-review) invalid, sorry > usertags 505251 requested No valid user selected > End of message, stopping processing here. […] - End forwarded message - It there a recommended naming scheme for setting up usertags in a sensible way? Is it really important that the user name is an email address? Do I have to use something like [EMAIL PROTECTED], or [EMAIL PROTECTED] Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
William Pitcock <[EMAIL PROTECTED]> (08/12/2008): > Unless you're talking about the ugly XMMS GUI. In which case, I > believe QMMS is available for packaging. So says an audacious packager and upstream author. Pot. Kettle. Black. Mraw, KiBi. signature.asc Description: Digital signature
Bug#508168: ITP: wulfware -- a software suite for monitoring nodes in a cluster
Package: wnpp Severity: wishlist Owner: Morten Kjeldgaard <[EMAIL PROTECTED]> * Package name: wulfware Version : 2.6.0 Upstream Author : Robert G. Brown <[EMAIL PROTECTED]> * URL : http://www.phy.duke.edu/~rgb/Beowulf/wulfware/ * License : GPL Programming Lang: C Description : a cluster monitoring suite wulfware is a suite of applications that provide remote monitoring information on a beowulf- or GRID-style compute cluster, a server farm, or LAN. It consists of the following tools: . * xmlsysd, a daemon that runs on the host to be monitored. xmlsysd can be run under xinetd or as a standalone forking daemon. It extracts information from /proc, from systems calls, and from selected tools or files, packs it into a set of XML tags, and returns that information to the connected monitor host(s). The daemon can be throttled to return only the information a monitor interface requires to support a particular display. . * wulfstat, an ncurses based monitor interface. wulfstat permits one to monitor an entire cluster or LAN. Statistics it provides include a vmstat-like display, load averages only, network statistics only, memory information only, system configuration information and duty cycle only, and running processes with or without the full command line. A cluster or LAN can easily be defined with a few simple commands in an XML-based "wulfhosts" file. . * wulflogger, a command line monitor interface that extracts more or less the same data as wulfstat in similarly named displays and writes them in formatted lines to stdout. This data format can easily be parsed by scripting languages such as perl or python, or it can be piped into a file for an archival record of cluster activity. The data can thus be used to generate a variety of reports, including web or graphical reports. . * wulfweb, an perl-cgi script to generate a web view of cluster statistics using wulflogger. Currently this is basically a working perl template for data extraction that can be modified into whatever kind of display one likes. libwulf, the common library upon which wulfstat and wulflogger are based. It encapsulates the routines that parse wulfhosts and build the requisite data structures, manage the connections to all hosts, and poll all connected hosts and extract the desired data from the xmlsysd return. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Le lundi 08 décembre 2008 à 08:25 -0600, William Pitcock a écrit : > On Sat, 2008-12-06 at 19:08 +0100, Josselin Mouette wrote: > > Gah, I thought it was able to handle SNES ROMs. The correct answer would > > probably be zsnes, although it only works on i386. > > Actually, gsnes9x can just be dropped. It is just a frontend to snes9x > (which, afaik, uses Xlib directly). If you want to replace gsnes9x which is a frontend, you need another frontend, or another emulator with a builtin frontend. Otherwise this is like proposing to replace a file manager with a shell. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#508169: ITP: bmakiosk -- Iceweasel/Firefox kiosk extension
Package: wnpp Owner: Free Ekanayaka <[EMAIL PROTECTED]> Severity: wishlist * Package name: bmakiosk Version : 2.13 Upstream Author : Pete Collins, Jim Massey, Martin.T.Kutschker * URL or Web page : https://addons.mozilla.org/en-US/firefox/addon/509 * License : MPL Description : Iceweasel/Firefox kiosk extension Commissioned by the Brooklyn Museum, the Mozilla Kiosk is an extension to the Mozilla web browser that enables a secure kiosk mode. Basically, it's meant for use anywhere that's anonymous, public, semi-public, and/or shared, or that requires special security precautions, such as public kiosks and library/learning center web terminals, or as a secure browser for terminal server sessions. It's the best, most useful kiosk-mode browser available today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
William Pitcock wrote: > Unless you're talking about the ugly XMMS GUI. In which case, I believe > QMMS is available for packaging. You meant 'QMMP'? It reproduces XMMS GUI and it is in unstable already. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com Ukrainian C++ Developer, Debian APT contributor signature.asc Description: OpenPGP digital signature
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: > Rene Engelhard <[EMAIL PROTECTED]> >aria > => gwget You're kidding? gwget does not have many features aria has. >manedit > => gmanedit Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Le lundi 08 décembre 2008 à 16:27 +0100, Rene Engelhard a écrit : > Josselin Mouette wrote: > > Rene Engelhard <[EMAIL PROTECTED]> > >aria > > => gwget > > You're kidding? gwget does not have many features aria has. This is just a first guess based on the description. If you want to still see these features in the future, you should consider porting aria to GTK+ 2.x or porting the features to gwget. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: BTS usertag with an userid that is not an email address.
On Mon, Dec 8, 2008 at 11:44 PM, Charles Plessy <[EMAIL PROTECTED]> wrote: > I am doing some pilot tagging to implement my idea of peer review for the > `debian/copyright' file. How about using user [EMAIL PROTECTED], usertag copyright-review-requested for this purpose? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: > Le lundi 08 décembre 2008 à 16:27 +0100, Rene Engelhard a écrit : > > Josselin Mouette wrote: > > > Rene Engelhard <[EMAIL PROTECTED]> > > >aria > > > => gwget > > > > You're kidding? gwget does not have many features aria has. > > This is just a first guess based on the description. > > If you want to still see these features in the future, you should > consider porting aria to GTK+ 2.x or porting the features to gwget. I am not arias upstream. I won't do a Gtk1.2->2.0 port yourself. (acttually I only used it very rarely and nowadays almost never, so in emergency can be removed, it'd dead upstream anyway and as the (console) aria2) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508185: ITP: jslib -- Iceweasel/Firefox javaScript library
Package: wnpp Owner: Free Ekanayaka <[EMAIL PROTECTED]> Severity: wishlist * Package name: jslib Version : 0.1.359 Upstream Author : Eric Plaster, Brian King, Pete Collins * URL or Web page : http://jslib.mozdev.org/ * License : MPL Description : Iceweasel/Firefox javaScript library An Iceweasel/Firefox extension whose goal is to make life easier for Mozilla application developers by providing a general purpose library that is simple and easy to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508188: ITP: maven-resources-plugin -- Maven resources plugin
Package: wnpp Severity: wishlist Owner: Torsten Werner <[EMAIL PROTECTED]> * Package name: maven-resources-plugin Version : 2.3 Upstream Author : Apache Software Foundation * URL : http://maven.apache.org/plugins/maven-resources-plugin/ * License : Apache-2.0 Programming Lang: Java Description : Maven resources plugin Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. . Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with: . * Making the build process easy * Providing a uniform build system * Providing quality project information * Providing guidelines for best practices development * Allowing transparent migration to new features . The Resources Plugin handles the copying of project resources to the output directory. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Mon, 08 Dec 2008 14:35:46 +0100 Morten Kjeldgaard <[EMAIL PROTECTED]> wrote: > I am quite willing to adopt the package and maintain it, but I > couldn't find > it on the list of orphans. Maybe I didn't look hard enough? That list > is enormous... :-( All the more reason to remove any package that has been orphaned since before the Etch release before Lenny. > On a side note, I already am attempting to adopt a companion for GTK+ > 1.2, namely gktglarea [1]. The modified package is on mentors and I am > looking for > a sponsor [2] (nudge nudge :-)) gtkglarea already has a Gtk+2.0 version, why add the 1.2 version again? It is not a companion, it is an abandoned reverse dependency that is dead upstream, unmaintained, unloved and unwanted. See #492994 I covered this issue when looking at the NMU for gdis to use libgtkgl2.0-dev instead. I think we should remove gtkglarea, not be sponsoring its adoption. Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. > > In our experience with GAMGI (http://www.gamgi.org/), GTK+ 1.2 was > > indeed useful to prepare a preliminary package that helped to > > convince Upstream to GTK 2.0. > > Good point! No, not a good point at all, a very poor point. GTK+2.0 is just as simple to use from a clean codebase. There is no need to build for Gtk1.2 and then port to Gtk+2.0 - just go straight for 2.0. (And yes, I have done this more than once and I can attest from real experience that Gtk1.2 is not a sane development choice for *ANY* project. Newly written code simply must not use Gtk1.2, it is completely insane to do so.) > > I am the first author of GAMGI (http://www.gamgi.org/), which > > depends on Mesa, Expat, Freetype 2, Glib 1, Gtk 1, Gtkglarea1, > > that's why I am so keen about compiling these libraries myself. No - the only sane choice for new code is glib2.0, Gtk+2.0 and libgtkgl2.0 - read the API docs, Gtk1.2 and glib1 are *NOT* for use with newly written code. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpIAFoS3wgZT.pgp Description: PGP signature
Re: Packages still depending on GTK+ 1.2
Neil Williams wrote: Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. Neil, My apologies but I just uploaded it. It still has a few r(b)depends: rdepends: xt worlded vertex python-visual rbdepends: celestia vertex xt Sorry, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Mon, 08 Dec 2008 14:24:13 -0500 Barry deFreese <[EMAIL PROTECTED]> wrote: > Neil Williams wrote: > > > > Barry - PLEASE do not continue with the request for sponsorship of > > gtkglarea. > > > > > Neil, > > My apologies but I just uploaded it. It still has a few r(b)depends: and will still be removed if libgtk1.2 is finally removed. The list of reverse dependencies make no difference - those depend on libgtk1.2 and would need to either migrate or be removed. Not sponsoring the upload was a chance to further the goal of removing gtk1.2 - it was an opportunity that has now been missed. The objective remains the same. > Sorry, > > Barry deFreese Has my response changed your opinion of gtkglarea in Debian? You could always join the calls for packages depending on gtkglarea to migrate to libgtkgl2.0 and thereby support the removal of gtk1.2 and glib1. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpL6OsR4M7eP.pgp Description: PGP signature
Re: Packages still depending on GTK+ 1.2
Hi, Barry deFreese wrote: > Neil Williams wrote: >> >> Barry - PLEASE do not continue with the request for sponsorship of >> gtkglarea. >> ... > My apologies but I just uploaded it. It still has a few r(b)depends: Well, post-lenny, all of them will be RC-buggy when GTK+ 1.2 is removed. gtkglarea might as well have a maintainer as long as its around. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Neil Williams wrote: Has my response changed your opinion of gtkglarea in Debian? You could always join the calls for packages depending on gtkglarea to migrate to libgtkgl2.0 and thereby support the removal of gtk1.2 and glib1. Not at all. In fact even for Lenny I attempted to do some porting and/or uploads of new upstream where possible. I'd personally love to see it go but I'm just one lowly new DD in a sea of people with much more skills than I. :) Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard dijo [Sat, Dec 06, 2008 at 01:50:44AM +0100]: > > However, I maintain my objection. One thing is removing out-of-date > applications, another is to remove a library which may well be used > by users to compile and link their local applications. Even though > there are no apps in Debian linking to GTK+ 1.2 the library should > really remain in the archives. Sometimes, old bits just have to die. And it is painful. FWIW, for Etch->Lenny upgrades, some people will go through the pain that means no longer having Apache 1.x (as some of its modules are not available for 2.x or not API-compatible). Should we keep obsolete, deprecated, abandoned software forever? Hmmm... Sounds like an argument for porting Debian to the C64. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On 08/12/2008, at 20.55, Gunnar Wolf wrote: . Should we keep obsolete, deprecated, abandoned software forever? No, certainly not forever. Nobody has suggested keeping GTK+ 1.2 forever. Hmmm... Sounds like an argument for porting Debian to the C64. It's great if you can present your own arguments, and I'd like to understand what your position is. Please stop exaggerating and ridiculing my POV. It's a dumb rhetorical trick that populist politicians use ad infinitum but it does not belong in this community. One of the purposes of Debian and the FOSS community is to make it possible to develop and distribute software that is authored and supported by volunteers. We have a responsibility of supporting software components that are still being used by people. There are people other than Debian Developers using the distribution, they might not be using the latest versions of the toolkits, but that is their choice. As long as there is interest in the FOSS community for a specific component, it should be maintained in Debian. I am not saying that all rdepends of GTK+ 1.2 should be kept in the distribution. My position is that it is too early to retire the library GTK+ 1.2. I have offered to maintain it. If you want to change my opinion on this, you have to present valid arguments and not ridicule and/or exaggerations. Cheers, Morten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Mon, 8 Dec 2008 21:49:09 +0100 Morten Kjeldgaard <[EMAIL PROTECTED]> wrote: > One of the purposes of Debian and the FOSS community is to make it > possible to develop and distribute software that is authored and > supported by volunteers. True. > We have a responsibility of supporting > software components that are still being used by people. Hmmm, no - not completely, not even if you add the missing "free" in front of 'software components'. Still being used is not a safe or sane criterion, still being supported is more important. Bit rot is the constant enemy and there is no good reason to retain unsupported code in Debian. You say you have offered to maintain gtk1.2 but that is not the complete solution - it is dead upstream and that severely compromises the "value" of merely having a willing maintainer in Debian, unless that maintainer also takes over upstream maintenance of the codebase which, frankly, makes absolutely no sense. Again, I have done this and I continue to do this - I try never to speak from a position that I have not experienced personally. Taking over upstream is a significant burden and it is immensely stupid to take over maintenance of a codebase that has already been replaced and for which a clear, supported and proven upgrade path is both well established and thoroughly debugged. For one thing, such a choice glibly ignores all the bug fixes made in the new version - those simply cannot be backported to gtk1.2 because the bug fix needs to be implemented via a restructuring of the code that will force a SONAME bump. > There are > people other than Debian Developers using the distribution, they > might not be using the latest versions of the toolkits, but that is > their choice. Then their choice can be supported by oldstable. That is no justification for using gtk1.2 with newly written code in unstable. Choices have consequences - one consequence of choosing gtk1.2 for newly written code is that people who know a whole lot more than you about writing secure, portable, usable code get a chance to laugh at you hysterically because you made such an insane choice. The fact that someone chooses gtk1.2 does not mean that Debian has any responsibility to include that code - in fact it means the exact reverse. Debian has a responsibility to provide stable, secure, portable code. gtk1.2 is none of those things, not any more. I have written code using it, I have debugged code written against it, I have ported packages away from it and I can say with some degree of certainty that gtk1.2 is *not* stable, secure or portable against the versions of other libraries in unstable. Things have moved on and gtk1.2 has been left behind - DELIBERATELY. That situation can only ever get worse - nothing will ever be improved within gtk1.2 - that alone makes it insane to write new code that uses gtk1.2. How are you going to fix a new security bug in gtk1.2 should it come along? > As long as there is interest in the FOSS community for > a specific component, it should be maintained in Debian. WRONG WRONG WRONG. As long as there is SUPPORT in the FOSS community for a specific component then it CAN be maintained in Debian. There is no 'should' involved. Debian has absolutely NO responsibility to package any specific piece of software, especially unsupported libraries. Support means upstream support, not merely a Debian maintainer. Nobody can require that Debian contains a specific package. I've said this many times, Debian is categorically not a dumping ground for every piece of bit rot free software on the internet and beyond. I deliberately include gtk1.2 in the category of bit rot software. Equally, I will consider libqof1 (my own upstream library) bit rot software as soon as I release libqof2 after Lenny. Don't come crying to me looking for support for libqof1 after that date as the reply is guaranteed to offend. I have taken sufficient steps to ensure that all reverse dependencies can already work with libqof2 but this is easy for me because there aren't many of them. The problem with Gtk is the sheer weight of reverse dependencies and the sad reality is that some of those packages *MUST* die simply to ensure that gtk1.2 can be laid to rest in peace for evermore. gtk1.2 deserves to be removed - it is unsupportable and your offer to maintain it makes me seriously doubt whether you understand what is actually required to do so. > I am not saying that all rdepends of GTK+ 1.2 should be kept in the > distribution. My position is that it is too early to retire the > library GTK+ 1.2. I have offered to maintain it. Maintaining it is insufficient and taking on the upstream codebase is completely insane. The code is dead, long long dead. There are no sane reasons to use gtk1.2 code in any newly written code - that includes within gtk1.x itself. If you doubt my assessment, speak to any of the authors of gtk1.2. > If you want to change my opinion on this, you have to present valid
Re: New ftpteam member
2008/12/8 Joerg Jaspert <[EMAIL PROTECTED]>: > lets have some good news for a change: Everybody, please welcome Frank > Lichtenheld as a new member of the FTP Team. Congratz, Frank. Welcome :) And they said that there was no German cabal? :P Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard dijo [Mon, Dec 08, 2008 at 02:35:46PM +0100]: > > With its thousands of packages, Debian is not so rich in manpower, so if > > the current maintainers of GTK+ 1.2 want to abandon it and the QA team is > > not interested in keeping it, there is no other choice than to adopt it > > (and its 43 bugs) if you want it to stay in Debian. It had less than upload > > per year since 2003, so maybe it is doable. Also, I think that it is > > possible to opt-out security support if this an issue (but it might make > > the package unfit for release). > > I must admit I was under the impression from this discussion that GTK+ > 1.2 was > simply _unwanted_ in Debian due to reasons of out-of-dateness and possible > security problems... > > I am quite willing to adopt the package and maintain it, but I couldn't > find > it on the list of orphans. Maybe I didn't look hard enough? That list is > enormous... :-( As others have said in this thread... Yes, Gtk1.2 could survive if people were willing to adopt it and keep it maintained... But there _is_ a strong consensus against stale, unneeded software not supported upstream anymore (and for several years). Keeping Gtk in Debian encourages people not to take a look at the code they wrote a decade ago, which might be full of bugs, or even of what the "Agile programming" crowd call "smells" - All sorts of programming practices that have become obsoleted (or outright shown to be dangerous) over the years. As an example - Around ten years ago few people would have thought about the security implications of an integer overflow or format string attacks. There are, yes, tens of packages still in Debian which depend on Gtk1.2. However, many of us have the opinion that, if they are worthy enough, somebody will have the interest and time to port them to Gtk2. Try and do the same to your pet programs - you will do a much bigger service than by maintaining Gtk1.2. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard dijo [Sat, Dec 06, 2008 at 02:27:00PM +0100]: > > For whom is the Debian distribution? Is it created to satisfy the > needs of only the packagers and developers? If so, it is absolutely > logical to get rid of everything a couple of years past expiry date. > > To be clear, we are not talking about applications for which a > replacement -- often better -- exists. We are talking about > libraries. In my opinion, Debian is also for programmers who don't > package their software for the distribution, but distribute it > themselves or don't distribute it at all. > > I mentioned science programs, and these are typical examples where > the authors are not programmers who are geekily fascinated with > every new incarnation of a graphics toolkit, but are more interested > in developing the methods, applicability and scope of their own > algorithms. If the menu system and dialogue boxes work, why spend > more time on it? > > You may disagree with the above reasoning, but it is a fact of life > of many Debian users, and it is arrogant to disregard. I like your reasoning, but I disagree. As a distribution, we have a committment to give proper support for our users. But if a package is dead upstream, the best advice you can give your users is, "you have ~2 years (i.e. a stable release cycle) to do this change, please allocate some resources to it". And, yes, I understand your point regarding science programs (I work at a University and know the ways of academics). And I also understand there is _great_ work done by people who have completely retired and won't maintain it anymore. That's where we step in. If _you_ want a given science program to keep being part of Debian, well... The author will be very grateful if you help him port it to a modern incarnation of this toolkit. It will also increase his visibility and decrease his frustration, as most distributions don't (or won't at some point in time) ship Gtk1.2 - If he decides to switch away from Debian or has a student which likes Fedora for his laptop, he will still want to install his software. Integration- and quality-wise, it is _our_ job to deprecate bitrotten code. > GTK+ 1.2 is not just any old library. It was the first truly open > and free graphics toolkit of excellent quality, an alternative to > Motif and the ugly Xaw widget sets, and was eagerly embraced by > everyone. This is a central and historic piece of software. And, hey, libc5 is also a core piece of our collective history - The first widely distributed version of a free, GNU C library! Oh, and so is XFree, particularly the 3.x branch. Not to forget, of course, Emacs19 and XEmacs. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Morten Kjeldgaard dijo [Mon, Dec 08, 2008 at 09:49:09PM +0100]: > >. Should we keep obsolete, deprecated, > >abandoned software forever? > > No, certainly not forever. Nobody has suggested keeping GTK+ 1.2 forever. But... There will always be a little tail of tools wanting it. We will have to drop those tools at some point in time. > >Hmmm... Sounds like an argument for porting Debian to the C64. > > It's great if you can present your own arguments, and I'd like to > understand what your position is. Please stop exaggerating and > ridiculing my POV. It's a dumb rhetorical trick that populist > politicians use ad infinitum but it does not belong in this > community. Yes... Sorry, I recognize my sarcastic tone, and would love to edit it back in my ~3min-old post. It is... Our standard flamish attitude ;-) (no offence meant to people from the Netherlands) But still, I hope you can unearth my true motivation from under my sarcasm, and discard what's worthless in my message. I think I have answered to the rest of your mail in other posts. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New ftpteam member
>> lets have some good news for a change: Everybody, please welcome Frank >> Lichtenheld as a new member of the FTP Team. > Congratz, Frank. Welcome :) > And they said that there was no German cabal? :P Want to volunteer and possibly join too, to get some non-german blood in? -- bye, Joerg Some NM: "Essential: Yes" -- useful for a message when you do apt-get remove bash: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS usertag with an userid that is not an email address.
Le Tue, Dec 09, 2008 at 12:33:12AM +0900, Paul Wise a écrit : > On Mon, Dec 8, 2008 at 11:44 PM, Charles Plessy <[EMAIL PROTECTED]> wrote: > > > I am doing some pilot tagging to implement my idea of peer review for the > > `debian/copyright' file. > > How about using user [EMAIL PROTECTED], usertag > copyright-review-requested for this purpose? Hello debian-legal, I am thinking about a usertag system to request peer reviews of debian/copyright files. Apparently it is not possible to use usertags without providing an email address. Would you mind if I use [EMAIL PROTECTED] for this purpose? As far as I understand there is no functionality in the BTS to send emails to the user based on his tags, so it should not increase the traffic on the list. Have a nice day, and thanks Paul for the idea, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Le Mon, Dec 08, 2008 at 04:25:56PM -0600, Gunnar Wolf a écrit : > All sorts of programming practices > that have become obsoleted (or outright shown to be dangerous) over > the years. As an example - Around ten years ago few people would have > thought about the security implications of an integer overflow or > format string attacks. Hi all, seecurity is of course important, but as I was told during the last DPL debate, it is possible to opt out support from the security team, which is only for Stable anyway. Buffer overflows are not the same issues when viewing downloaded PDFs from anywhere compared to viewing molecules which structure is downloaded from a curated databank or from a local structural biology facility. Why not keeping in Debian a package that helps people to compile software that is useful and is not broken? It does not cost manpower to Debian: nobody in this thread has asked for security support, and Morten has proposed to releive the GNOME team from the burden. As for scientific software, nobody will find the time or the money to upgrade from GTK1.2 to GTK2 only for the beauty of it. People are rewarded on their new developments, not on code maintainance. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New ftpteam member
2008/12/9 Joerg Jaspert <[EMAIL PROTECTED]>: > >> And they said that there was no German cabal? :P > > Want to volunteer and possibly join too, to get some non-german blood in? I'm half German, at least by heart, you already know ;) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted suitesparse 3.2.0-1 (source all i386)
Hi, Christophe Prud'homme wrote: > suitesparse (3.2.0-1) unstable; urgency=low WTF? > Accepted: > libsuitesparse-3.2.0_3.2.0-1_i386.deb > to pool/main/s/suitesparse/libsuitesparse-3.2.0_3.2.0-1_i386.deb > libsuitesparse-dbg_3.2.0-1_i386.deb > to pool/main/s/suitesparse/libsuitesparse-dbg_3.2.0-1_i386.deb > libsuitesparse-dev_3.2.0-1_i386.deb > to pool/main/s/suitesparse/libsuitesparse-dev_3.2.0-1_i386.deb > libsuitesparse-doc_3.2.0-1_all.deb > to pool/main/s/suitesparse/libsuitesparse-doc_3.2.0-1_all.deb > suitesparse_3.2.0-1.diff.gz > to pool/main/s/suitesparse/suitesparse_3.2.0-1.diff.gz > suitesparse_3.2.0-1.dsc > to pool/main/s/suitesparse/suitesparse_3.2.0-1.dsc > suitesparse_3.2.0.orig.tar.gz > to pool/main/s/suitesparse/suitesparse_3.2.0.orig.tar.gz Nice. Uploading a NEW PACKAGE NAME version of suitesparse, breaking all of the following reverse-deps: [EMAIL PROTECTED]:~$ grep-available -FDepends libsuitesparse-3.1.0 -sPackage Package: libsuitesparse-dev Package: illuminator-demo Package: libluminate7 Package: python-scipy Package: libpetsc2.3.3 Package: openoffice.org-calc Package: lp-solve Package: octave3.0 Package: octave3.1 Package: python-sparse Package: freemat Package: libsuitesparse-dbg (and openoffice.org-core in turn depends on lp-solve). When those now get rebuilt in sid against the new suitesparse (and they need to because they will become uninstallable when libsuitesparse-3.1.0 semi-automatically get removed) they can't be fixed via sid anymore. Did you EVER hear of the freeze? Upload such stuff to experimental. Anyway, we discussed that quickly on #debian-relese. Reverted. Will NMU with epoch uploading 3.1.0 again. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Charles Plessy wrote: [...] > > Hi all, > > seecurity is of course important, but as I was told during the last DPL > debate, it is possible to opt out support from the security team, which is > only for Stable anyway. > There's a testing security team in case you were not aware of it. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Tue, Dec 09, 2008 at 08:48:34AM +0900, Charles Plessy wrote: > Le Mon, Dec 08, 2008 at 04:25:56PM -0600, Gunnar Wolf a écrit : > > All sorts of programming practices > > that have become obsoleted (or outright shown to be dangerous) over > > the years. As an example - Around ten years ago few people would have > > thought about the security implications of an integer overflow or > > format string attacks. > > Hi all, > > seecurity is of course important, but as I was told during the last DPL > debate, > it is possible to opt out support from the security team, which is only for > Stable anyway. > > Buffer overflows are not the same issues when viewing downloaded PDFs from > anywhere compared to viewing molecules which structure is downloaded from a > curated databank or from a local structural biology facility. Why not keeping > in Debian a package that helps people to compile software that is useful and > is > not broken? It does not cost manpower to Debian: nobody in this thread has > asked for security support, and Morten has proposed to releive the GNOME team > from the burden. Keeping your name as Maintainer in debian/control is not maintaining. If all that is going to happen to the package is that (and I'm pretty sure it would), having people who need gtk1.2 take it from oldstable is exactly the same: no security support, no change to the package, and no maintenance burden. It has the added value that people can know all that by the fact it is in oldstable and not in stable anymore. Why are people so unwilling to use oldstable? It happened to me to have to use a package from it for an old proprietary crap using a bitrot libstdc++, but I don't expect the package I took there to be in stable, let alone unstable. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: autodie -- Replace functions with ones that succeed or die with lexical scope
Package: wnpp Severity: wishlist Owner: "Jeremiah C. Foster" <[EMAIL PROTECTED]> * Package name: libautodie-perl Version : 1.997 Upstream Author : Paul Jamieson Fenwick <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~pjf/autodie-1.997/lib/autodie.pm * License : GPL, ARTISTIC Programming Lang: Perl Description : Replace functions with ones that succeed or die with lexical scope The autodie pragma provides a convenient way to replace functions that normally return false on failure with equivalents that throw an exception on failure. The autodie pragma has lexical scope, meaning that functions and subroutines altered with autodie will only change their behaviour until the end of the enclosing block, file, or eval. If system is specified as an argument to autodie, then it uses IPC::System::Simple to do the heavy lifting. See the description of that module for more information. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New ftpteam member
On Tue, Dec 09, 2008 at 12:23:04AM +0100, Joerg Jaspert wrote: > > And they said that there was no German cabal? :P > Want to volunteer and possibly join too, to get some non-german > blood in? I'm disappointed: I expected a reply in German :-P -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime signature.asc Description: Digital signature
ITP: IPC::System::Simple -- Run commands simply, with detailed diagnostics
Package: wnpp Severity: wishlist Owner: "Jeremiah C. Foster" <[EMAIL PROTECTED]> * Package name: libipc-system-simple-perl Version : 0.16 Upstream Author : Paul Jamieson Fenwick <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~pjf/IPC-System-Simple-0.16/lib/IPC/System/Simple.pm * License : GPL, Artistic Programming Lang: Perl Description : Run commands simply, with detailed diagnostics Calling Perl's in-built system() function is easy, determining if it was successful is hard. Let's face it, $? isn't the nicest variable in the world to play with, and even if you do check it, producing a well- formatted error string takes a lot of work. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
