Re: Packages still depending on GTK+ 1.2
GTK+ 1.2 has been deprecated upstream for 6 years. There is no security support for it, and no new applications using it have been out for quite a long time as well. Here is a first list of packages that could either be removed right now because they seem to have replacements, or updated with little work. If there are no objections, I think we should ask for removal of all of those which don’t have a GTK+ 2 version. Drew Parsons dpars...@debian.org zangband = yay, a rogue game zangband has features not present in other rogue clones, namely an outdoor wilderness environment connecting different towns and different dungeons. The chief charm of the rogue clones is their beautiful ascii animation. To my mind the gtk interface is a step backwards which defeats the point of these dumb but addictive little games. There is no need to remove zangband, we can simply drop the gtk build instead if required. Drew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packages still depending on GTK+ 1.2
On Fri, 05 Dec 2008 19:06:26 +0100 Josselin Mouette [EMAIL PROTECTED] wrote: Tim Dijkstra [EMAIL PROTECTED] digitaldj = prokyon3 It still works, some people still use it... so I do not see any need to remove it now. If the time comes to remove gtk+1.2, digitaldj can go too IYAM. I'm not using it anymore, and certainly do not have the time to port it. grts Tim signature.asc Description: PGP signature
Re: Packages still depending on GTK+ 1.2
Le jeudi 11 décembre 2008 à 11:46 +0100, Tim Dijkstra a écrit : It still works, some people still use it... so I do not see any need to remove it now. If the time comes to remove gtk+1.2, digitaldj can go too IYAM. I'm not using it anymore, and certainly do not have the time to port it. As this reaction is quite common, maybe I should make things more clear. * Yes, GTK+ 1.2 is going away before the squeeze release. * If everyone says “I’m going to remove my pet package when it is the last one”, it is obvious that we are never going to remove it. -- .''`. : :' : 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 Thu, 11 Dec 2008 14:12:04 +0100 Josselin Mouette [EMAIL PROTECTED] wrote: Le jeudi 11 décembre 2008 à 11:46 +0100, Tim Dijkstra a écrit : It still works, some people still use it... so I do not see any need to remove it now. If the time comes to remove gtk+1.2, digitaldj can go too IYAM. I'm not using it anymore, and certainly do not have the time to port it. As this reaction is quite common, maybe I should make things more clear. * Yes, GTK+ 1.2 is going away before the squeeze release. * If everyone says “I’m going to remove my pet package when it is the last one”, it is obvious that we are never going to remove it. Can we, therefore, just say that unless maintainers remove the package themselves after the Lenny release, all reverse dependencies of gtk1.2 and gtk1.2 itself will be removed from Debian during the month before the expected announcement of the Squeeze toolchain freeze? i.e. at the earliest stage of the Squeeze release process. (No delays would be accepted for this removal either, it would be unavoidable and no complaints would be entertained, no matter what.) I'm happy to help get rid of gtk1.2. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpFpYHPsklqL.pgp Description: PGP signature
Re: Packages still depending on GTK+ 1.2
On Thu, 11 Dec 2008, Josselin Mouette wrote: As this reaction is quite common, maybe I should make things more clear. * Yes, GTK+ 1.2 is going away before the squeeze release. * If everyone says “I’m going to remove my pet package when it is the last one”, it is obvious that we are never going to remove it. I don't read Tim's message like this. I read: Just remove GTK+ 1.2 and once this is done my pet package becomes RC buggy. The fix for the bug is removing the package. That's quite simple and Tim in this message agrees to this procedure (as well as I did). Kind regards Andreas. -- http://fam-tille.de
Re: Packages still depending on GTK+ 1.2
On Thu, Dec 11, 2008 at 10:35 PM, Neil Williams [EMAIL PROTECTED] wrote: Can we, therefore, just say that unless maintainers remove the package themselves after the Lenny release, all reverse dependencies of gtk1.2 and gtk1.2 itself will be removed from Debian during the month before the expected announcement of the Squeeze toolchain freeze? i.e. at the earliest stage of the Squeeze release process. (No delays would be accepted for this removal either, it would be unavoidable and no complaints would be entertained, no matter what.) I'm happy to help get rid of gtk1.2. I think it would be better to remove gtk1.2 and it's reverse dependencies as soon as the 'squeeze' codename exists. That would give people more time and (more importantly) motivation to work on porting apps. People will inevitably complain, perhaps removing them from testing first and unstable a few months later would be best. -- 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
On Thu, Dec 11, 2008 at 02:12:04PM +0100, Josselin Mouette wrote: Le jeudi 11 d??cembre 2008 ?? 11:46 +0100, Tim Dijkstra a ??crit : It still works, some people still use it... so I do not see any need to remove it now. If the time comes to remove gtk+1.2, digitaldj can go too IYAM. I'm not using it anymore, and certainly do not have the time to port it. As this reaction is quite common, maybe I should make things more clear. * Yes, GTK+ 1.2 is going away before the squeeze release. * If everyone says ???I???m going to remove my pet package when it is the last one???, it is obvious that we are never going to remove it. I don't see any conflict here - all people are saying is that they'd rather do the removal of the dependant packages when GTK+ 1.2 is actually being removed from the archive. There appears to be relatively little opposition to the idea of removing GTK+ 1.2 itself. Possibly a good way to proceed here is to just remove GTK+ 1.2 shortly after lenny is released, unless we do actually identify any critical packages that still depend on it? -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Thu, 11 Dec 2008 14:42:08 +0100 (CET) Andreas Tille [EMAIL PROTECTED] wrote: On Thu, 11 Dec 2008, Josselin Mouette wrote: As this reaction is quite common, maybe I should make things more clear. * Yes, GTK+ 1.2 is going away before the squeeze release. * If everyone says “I’m going to remove my pet package when it is the last one”, it is obvious that we are never going to remove it. I don't read Tim's message like this. I read: Just remove GTK+ 1.2 and once this is done my pet package becomes RC buggy. The fix for the bug is removing the package. That's quite simple and Tim in this message agrees to this procedure (as well as I did). Indeed, that is what Tim meant to write;) grts Tim signature.asc Description: PGP signature
Re: Packages still depending on GTK+ 1.2
On 2008-12-05 19:06 +0100, Josselin Mouette wrote: OHURA Makoto [EMAIL PROTECTED] xemacs21 = maybe we need to wait for emacs23 I'm not sure that hardcore XEmacs users can be convinced to switch to Emacs, even if Emacs 23 will provide the necessary eye-candy that is lacking from Emacs 22. The differences in operating concept philosophy and the Lisp implementations are rather large. The good news is that while XEmacs is unlikely to be ported to GTK+ 2.0 anytime soon, support for GTK+ 1.2 is optional and XEmacs can be built without it, so xemacs21 will not have to be removed, only the xemacs21-gnome* packages have to go. Sven, not an XEmacs user -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Dear Neil Gunner, Thank you for your long, detailed and convincing postings in this thread. I really appreciate it! The argument that finally made me surrender was that time is perhaps better spent helping upstream authors make the conversion. So I guess we're on the same page now. And I'd be crazy not to listen to a couple of heavy-weight experienced DDs :-) Having said that, understand this: scientists are the most conservative programmers on the planet. As someone interested in bringing as many science programs into the distribution as possible, I think others in the science-teams agree that dealing with upstream can be an uphill battle! Things like copyright is almost never in order, the tarballs contain all kinds of strange files that require repackaging, man pages are almost never there, and the documentation is often scarce (of course there is often an associated article in a scientific journal). Upstream authors are always very positive, but there often a long waiting time for delivery. On top of this, asking a scientist for updating the software for a new version of a toolkit will come as an extra burden. Scientists will see this as endless quest for your own shadow. When they've finally gotten around to updating their software to GTK+ 2 (say), version 3 will have long replaced it. But perhaps that is the harsh reality of life for us in the science teams. 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 Tue, Dec 09, 2008 at 02:08:48PM +0100, Morten Kjeldgaard [EMAIL PROTECTED] wrote: Dear Neil Gunner, Thank you for your long, detailed and convincing postings in this thread. I really appreciate it! The argument that finally made me surrender was that time is perhaps better spent helping upstream authors make the conversion. So I guess we're on the same page now. And I'd be crazy not to listen to a couple of heavy-weight experienced DDs :-) Having said that, understand this: scientists are the most conservative programmers on the planet. As someone interested in bringing as many science programs into the distribution as possible, I think others in the science-teams agree that dealing with upstream can be an uphill battle! Things like copyright is almost never in order, the tarballs contain all kinds of strange files that require repackaging, man pages are almost never there, and the documentation is often scarce (of course there is often an associated article in a scientific journal). Upstream authors are always very positive, but there often a long waiting time for delivery. On top of this, asking a scientist for updating the software for a new version of a toolkit will come as an extra burden. Scientists will see this as endless quest for your own shadow. When they've finally gotten around to updating their software to GTK+ 2 (say), version 3 will have long replaced it. But perhaps that is the harsh reality of life for us in the science teams. You can replace science and scientists with almost anything in your text, it still applies. Scientific applications are not very different from a very lot of other applications in Debian. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Le mardi 09 décembre 2008 à 14:08 +0100, Morten Kjeldgaard a écrit : On top of this, asking a scientist for updating the software for a new version of a toolkit will come as an extra burden. Scientists will see this as endless quest for your own shadow. When they've finally gotten around to updating their software to GTK+ 2 (say), version 3 will have long replaced it. Fortunately, porting to GTK+ 3 is going to be *much* easier. I’ll post something about it as soon as the upstream release plans are official. 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: Packages still depending on GTK+ 1.2
Le Mon, Dec 08, 2008 at 06:40:48PM -0600, Raphael Geissert a écrit : There's a testing security team in case you were not aware of it. Stable and Testing security teams make great work. It is just a shame that random developers write package X could annoy the security team(s) instead of I personnaly disagree with package X being distributed in Debian for reason Y (that has nothing to do with security). This is really competing as number one cut-and-past excuse with Our priorities are our users and free software. 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
Josselin Mouette [EMAIL PROTECTED] (09/12/2008): Fortunately, porting to GTK+ 3 is going to be *much* easier. I’ll post something about it as soon as the upstream release plans are official. SCNR: 2to3.py Mraw, KiBi. signature.asc Description: Digital signature
Re: Packages still depending on GTK+ 1.2
Charles Plessy dijo [Tue, Dec 09, 2008 at 08:48:34AM +0900]: 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. Agree on this - But the moment you are providing a library (and specially a library that was hugely popular in the past), you are opening the door to all kinds of applications to use it. Yes, I can code up a perfectly secure Gtk1.2 app that interacts only with me, but having a stale library in our pool makes people be creative about it... Or makes people ITP an old, abandoned but great tool not once updated since 1999. 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. Agree. But people might willing to invest some energy into porting their eight year old applications so they run on any modern-day distribution. And if they are sure their application runs with closed, secure data, and if the application is production-quality and does not need to be touched... Well, you can perfectly keep a cluster of Woody machines for a long time! -- 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
Hi folks, In case any of you are interested/care. Just for kicks I started digging through many of the r(b)depends for gtk+1.2. I have posted my notes here: http://people.debian.org/~bdefreese/gtk+1.2_rdepends_notes Yes, I know the format is hideous, sorry. I have already done some RM:s and NMUs for a couple of them. I will keep updating these notes if I get anywhere. If any of you maintain any of these packages and have any thoughts/suggestions/etc, please feel free to contact me. Thanks, 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 Tue, 2008-12-09 at 10:48 -0600, Gunnar Wolf wrote: 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. Agree. But people might willing to invest some energy into porting their eight year old applications so they run on any modern-day distribution. And if they are sure their application runs with closed, secure data, and if the application is production-quality and does not need to be touched... Well, you can perfectly keep a cluster of Woody machines for a long time! Or a separate repository created for the purpose of giving a longer life for these applications using ancient technology. I'm all for (re)moving GTK+ 1.2 from Debian. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] Debian Project signature.asc Description: This is a digitally signed message part
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: 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, Looks like snes9express is supposed to be another front-end that is gtk2.0 but it has never been part of a stable release. 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 Friday 05 December 2008, Josselin Mouette wrote: Hi, GTK+ 1.2 has been deprecated upstream for 6 years. There is no security support for it, and no new applications using it have been out for quite a long time as well. snip/ Cheers, Why not remove the -dev packages first. That way no package can be rebuilt or upgraded (it must be ported to the new version of the library) but users can continue to use the binaries until the library is finally removed. This way it would be obvious which packages need to be worked on. I realise that this would break the build-depends, but I suppose it is meant to. David -- 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, 9 Dec 2008 17:52:44 + David Goodenough [EMAIL PROTECTED] wrote: Why not remove the -dev packages first. That would make every reverse dependency instantly buggy with release-critical FTBFS bugs! No thanks! It must be possible to build all packages in Lenny only from the Debian source packages which, sadly, means retaining all -dev packages necessary for those builds. What we have must be buildable from source. I realise that this would break the build-depends, but I suppose it is meant to. It makes it impossible to release the reverse dependencies in Lenny. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpYp1fD6dRgr.pgp Description: PGP signature
Re: Packages still depending on GTK+ 1.2
On Tuesday 09 December 2008, Neil Williams wrote: On Tue, 9 Dec 2008 17:52:44 + David Goodenough [EMAIL PROTECTED] wrote: Why not remove the -dev packages first. That would make every reverse dependency instantly buggy with release-critical FTBFS bugs! No thanks! It must be possible to build all packages in Lenny only from the Debian source packages which, sadly, means retaining all -dev packages necessary for those builds. What we have must be buildable from source. I realise that this would break the build-depends, but I suppose it is meant to. It makes it impossible to release the reverse dependencies in Lenny. Well perhaps what is needed is a way of marking a package as deprecated, and this was what I was trying (badly) to achieve. Better to be explicit. This would trigger a warning whenever it was built rather than actually stopping it being build. That way package maintainers would gets warning in good time that they need to make the required changes before the package is actually removed. David -- 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, 9 Dec 2008 19:32:27 + David Goodenough [EMAIL PROTECTED] wrote: Well perhaps what is needed is a way of marking a package as deprecated, and this was what I was trying (badly) to achieve. Better to be explicit. Maybe Section: oldlibs needs to be more forcefully expressed? Any library in Section: oldlibs will be removed from Debian after the next stable release. That just moves the debate to the decision about when the library should change section. There will always be that point where some want it marked and some do not. There can be no hard-and-fast rule, each case has to be decided on merit which is where the disputes start. This would trigger a warning whenever it was built rather than actually stopping it being build. That way package maintainers would gets warning in good time that they need to make the required changes before the package is actually removed. I doubt that this would make a huge difference - it would have to be more than just a warning. To me, only having gtk1.2 in stable is a sufficient solution for now - i.e. make it impossible for any packages depending on gtk1.2 to be released in Squeeze. Maybe it's too late to remove gtk1.2 from Lenny, sadly. Marking a package as worth removal is a technical step - deciding if a package warrants such a tag cannot be reduced to a set of rules that would apply equally across all such cases, we need discussion and an eventual consensus. gtk1.2 shows that a consensus is unlikely to become unanimous and some people, some packages, will simply have to lose out. We can set guidelines for how to determine that point but I find it hard to see how a uniform set of rules can be devised to meet all such cases. We can try and say that a particular library must only have N number of SONAMEs in Debian at the same time but then we have libdb4.x to sort out first. We could say that a particular library must have no more than N number of reverse dependencies that have not migrated before being marked as warranting removal - in reality that would have to be a percentage but then we would probably have dropped GnuCash a long time before it was finally ported to Gtk+2.0, so the relative importance of the reverse dependencies comes into play. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpqxV8SqnVaz.pgp Description: PGP signature
Re: Packages still depending on GTK+ 1.2
Le Tue, Dec 09, 2008 at 08:03:31AM +0100, Mike Hommey a écrit : Why are people so unwilling to use oldstable Le Tue, Dec 09, 2008 at 10:48:29AM -0600, Gunnar Wolf a écrit : Well, you can perfectly keep a cluster of Woody machines for a long time! OK, I think that you have a good point: if removed in Lenny+1, GTK+1.2 will still be apt-gettable for around three years, and then hopefully forever from snapshots.debian.org. 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
On Wed, Dec 10, 2008 at 10:05 AM, Charles Plessy [EMAIL PROTECTED] wrote: OK, I think that you have a good point: if removed in Lenny+1, GTK+1.2 will still be apt-gettable for around three years, and then hopefully forever from snapshots.debian.org. And archive.debian.org, which includes sarge - Debian-0.93R6. -- 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
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: snip 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 :-)) snip 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]
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
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
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: 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]
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: snip Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. snip 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: snip Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. snip 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: snip Barry - PLEASE do not continue with the request for sponsorship of gtkglarea. snip ... 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: snip 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 arguments and not
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: 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]
Re: Packages still depending on GTK+ 1.2
Le Fri, Dec 05, 2008 at 10:41:52PM +0100, Morten Kjeldgaard a écrit : Please don't remove GTK+ 1.2. There are still upstream authors, especially in science who use GTK+ 1.2 and who don't bother revising their programs from the wisdom: if it ain't broke don't fix it. Hi Morten, 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). 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. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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
On Saturday 06 December 2008 23:15:06 Klaus Ethgen wrote: Am Sa den 6. Dez 2008 um 21:38 schrieb Daniel Moerner: xmms is gone: It is still in stable and there are many installations. More than 7000 in popcon. And there is still no alternative. IMHO audacious is a pretty decent alternative to xmms, though I prefer vlc for both audio and video. Of course your mileage may vary. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Sat, Dec 06, 2008 at 01:50:44AM +0100, Morten Kjeldgaard wrote: On 06/12/2008, at 00.09, Michael Banck wrote: There are several useful science programs that still make use of GTK+ 1.2, one is a very useful chemistry program, GAMGI, which is in the new queue and on its way into unstable. AFAICT, gamgi is using GTK-2.0. Yes you are right, gamgi uses GTK-2.0 as of March this year. I was quoting from (volatile, apparently) memory. 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. With such arguments, we would still ship every single bit that was shipped some day. This is going nowhere. Moreover, removing a package from the archive doesn't mean it will disappear at apt-get dist-upgrade time, not that it will disappear from archive.debian.org. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Fri, 5 Dec 2008, Josselin Mouette wrote: Andreas Tille [EMAIL PROTECTED] libgtkimreg paul = Yay, an imaging library and an image viewer As I said in a similar thread: These two packages should not block a GTK 1.2 removal but as long as the library is there they might remain. Just found a paul fan mail in my inbox. I confirm that paul is not maintained upstream (me) any more. It has features I do not know from any other viewer (that's why I started coding it 10 years ago) but it is not important enough to keep GTK 1.2just for this purpose. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On 06/12/2008, at 10.01, Mike Hommey wrote: With such arguments, we would still ship every single bit that was shipped some day. This is going nowhere. I don't recall advocating that every single bit that was shipped some day should be kept around. You are twisting my words and distorting my view into something obviously absurd. Moreover, removing a package from the archive doesn't mean it will disappear at apt-get dist-upgrade time, not that it will disappear from archive.debian.org. I've had this discussion several times before with people, but it doesn't hurt to repeat. 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. 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. So I am not advocating keeping every bit of software around. In this discussion, I am advocating keeping GTK+ 1.2 around. The LIBRARIES. I am not opposed to weeding out out-dated applications that make use of it, if reasonable replacements are available. But Libraries represent a resource for _others_ than packagers and developers. Cheers, Morten -- Morten Kjeldgaard [EMAIL PROTECTED] Key fingerprint = FC53 53B2 81D1 27CA 45D5 F864 078C F31B 4048 25E7 -- 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 wrote: snip 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. snip So I am not advocating keeping every bit of software around. In this discussion, I am advocating keeping GTK+ 1.2 around. The LIBRARIES. I am not opposed to weeding out out-dated applications that make use of it, if reasonable replacements are available. But Libraries represent a resource for _others_ than packagers and developers. Cheers, Morten Morten, I understand where you are coming from but it also becomes an issue of resources. We already have a buttload of orphaned and/or QA maintained packages. If we keep every version of every library out there how do we support it? Look at libnet0. It's orphaned but has several depends while libnet1 exists. Who's taking care of those users? Should we keep every version of glibc in the archive? How about all the gnome1 stuff? BTW, I don't care if GTK+ 1.2 stays or goes but I do care about unmaintained stuff hanging around. Just my worthless $.02 :) 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 Sat, Dec 06, 2008 at 09:20:31AM -0500, Barry deFreese wrote: Morten Kjeldgaard wrote: So I am not advocating keeping every bit of software around. If we keep every version of every library out there how do we support it? Morten did not say that. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Michael Banck wrote: On Sat, Dec 06, 2008 at 09:20:31AM -0500, Barry deFreese wrote: Morten Kjeldgaard wrote: So I am not advocating keeping every bit of software around. If we keep every version of every library out there how do we support it? Morten did not say that. Michael Obviously I was exaggerating purposely. Barry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Fri, Dec 5, 2008 at 7:06 PM, Josselin Mouette [EMAIL PROTECTED] wrote: Devid Filoni [EMAIL PROTECTED] dillo = there is a new upstream based on FLTK I'm working on fltk2 package in order to update dillo to the new upstream version that requires it. Devid Antonio Filoni -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
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. -- .''`. : :' : 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
Le samedi 06 décembre 2008 à 14:27 +0100, Morten Kjeldgaard a écrit : 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. If you agree to take over upstream maintenance - including security maintenance in imlib and gdk-imlib, maybe we could keep it around, yeah. -- .''`. : :' : 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 06/12/2008, at 15.47, Barry deFreese wrote: Obviously I was exaggerating purposely. Yes, but, you know, exaggerating the position of others in a forum like this is not really constructive. In fact, it signals that you've run out of arguments. I raised a -- I think -- valid concern that certain libraries can't just be removed just because they're old or not used anymore by most Debian apps, because they may still be useful to people who are not Debian Developers or package maintainers. The only argument I've read from various contributors to the thread is: we can't just keep every ancient bit of software that was once shipped. Again, ridiculing my position doesn't justify yours. However, earlier you said: BTW, I don't care if GTK+ 1.2 stays or goes but I do care about unmaintained stuff hanging around. Now that is a true concern, but OTOH it is a tangible problem that could be solved. So, if this is the case, why not try to solve the problem of maintenance for the software in question? I am speaking for GTK+ 1.2, I'll let others speak for software they care for. Btw, I can''t find GTK+ 1.2 on the Orphaned list. 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
Morten Kjeldgaard wrote: On 06/12/2008, at 15.47, Barry deFreese wrote: Obviously I was exaggerating purposely. Yes, but, you know, exaggerating the position of others in a forum like this is not really constructive. In fact, it signals that you've run out of arguments. Give me a break. I raised a -- I think -- valid concern that certain libraries can't just be removed just because they're old or not used anymore by most Debian apps, because they may still be useful to people who are not Debian Developers or package maintainers. The only argument I've read from various contributors to the thread is: we can't just keep every ancient bit of software that was once shipped. Again, ridiculing my position doesn't justify yours. No one is ridiculing you to my knowledge, that certainly isn't my intent. This kind of issue goes on constantly. It happened with wxwidgets, the gnome1 stuff, as I mentioned libnet0, and even to a smaller degree just within the games team with clanlib. We were holding on to an old version of clanlib for one game. However, earlier you said: BTW, I don't care if GTK+ 1.2 stays or goes but I do care about unmaintained stuff hanging around. Now that is a true concern, but OTOH it is a tangible problem that could be solved. So, if this is the case, why not try to solve the problem of maintenance for the software in question? I am speaking for GTK+ 1.2, I'll let others speak for software they care for. Btw, I can''t find GTK+ 1.2 on the Orphaned list. Cheers, Morten I wasn't talking about GTK+ 1.2 specifically. I'm talking about many of it's r(b)depends such as imlib, gnome-libs, etc in case GTK goes. Say a major security bug is found withing GTK. Now you have at least two dependent packages with lots of depends themselves that are effected but are unmaintained. Anyway, I'll shut up now as I said, I don't care if it stays or goes. Barry -- 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 [EMAIL PROTECTED] wrote: 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. You missed the word frontend in the above. gsnes9x is a simple frontend for snes9x-x. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Sat, Dec 06, 2008 at 04:25:17AM +0100, Josselin Mouette wrote: Le vendredi 05 d?cembre 2008 ? 22:49 +, Mark Brown a ?crit : It's nothing to do with power management. I'd rather let it stay until lenny is released, though if it were the only thing keeping GTK 1.2 in it should go. Does it even work? The description says it needs a /dev/cpu/ tree. Yes; as the description says the /dev/cpu stuff is only required by some of the features. If it were required for the package to work the package wouldn't be availible for so many architectures. Like I say, it can wait until we're actually removing GTK 1.2. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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).) Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSTrVmZ+OKpjRpO3lAQI47wf/aW5C59XUQfx44W5hqUYTI5bzUOn+5XAX BMEImtfjXBdQWgcaoJ8HUb7aQuWGvdRzElzo6nEfSwIcEzVKCWqDBONDxfn9AzWx rsFLryuOuyDs3yQVkOEumXmsX58LTGmPFsczG9/PXgjZYEUnw1PtDxrutG+8/i5J tGwq/QJ+urizK7eagmyz0wPfprJS0VyA6XsAWtfWgrd5S+rWjuBL6C+AwW3d+kyu bKgMLPGxotYSJ9ecH17EJSnCEuq3SVtEF0ON+0yhT6BuYIUfAkJfAMA9w1mJJNFq 4RAhz9OujpuDCMASrDcr66n17m9k7Q8pdIVhmLFjeNn4Vpd/RyUY8Q== =+5v9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Sat, Dec 6, 2008 at 11:42 AM, Klaus Ethgen [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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).) xmms is gone: [EMAIL PROTECTED]:~$ rmadison xmms xmms | 1:1.2.10+20061101-1etch1 | etch-m68k | source, m68k xmms | 1:1.2.10+20061101-1etch1 |stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461309 -- Daniel Moerner [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sa den 6. Dez 2008 um 21:38 schrieb Daniel Moerner: xmms is gone: It is still in stable and there are many installations. More than 7000 in popcon. And there is still no alternative. Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSTrrWp+OKpjRpO3lAQK9Uwf/WWeTKIT0OKrA2RzAZfAe9orxsedWx6gF 7/FrVKOsKF+FxbOugTCpDoW7iwFaSYsdm//otzgimGSQJ35theBEUcqPr2ilnI7l QOQAuY3DbmjKLHC0cmbjH3jKCBc7SfCJbtt81NSYX7/tTsyaxHhERBUYadDZyFBM CYJg/TPCbP1GQZ7nd/RQsez2m07KjB623ibf+IvFzUCh2I3I9w+7IUGNAU3sIKJS u3g9iiuYfhWS1JbN65sKXT12+72UI/42pshZmtTvypa3z5RY5uzn9tpxWiseO8rd KrX9Nvl4DkYTtherCPvFJg+5zZARMqBk9VbOX8t3M1J17BzPatTEFQ== =kuwI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Fri, 05 Dec 2008 19:06:26 +0100, Josselin Mouette wrote: Colin Watson [EMAIL PROTECTED] putty = hotwire, a plain terminal… According to http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ port-unix-gtk2.html, PuTTY trunk will build against GTK+ 2.0. \o/ -- Sam Morris https://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Sat, 6 Dec 2008 22:15:06 +0100 Klaus Ethgen [EMAIL PROTECTED] wrote: Am Sa den 6. Dez 2008 um 21:38 schrieb Daniel Moerner: xmms is gone: It is still in stable and there are many installations. More than 7000 in popcon. And there is still no alternative. Soon to be only in oldstable - sounds about right to me. If you want it back, please take on the work of migrating it to Gtk2.0. (Yes, I have already done this for other packages, before you ask. It isn't easy but it is the only realistic option.) Don't expect someone else to do it and don't complain if nobody bothers. You think xmms is so essential, you go and fix it. Simple really. Nobody else appears to want to do the work. Complaining about it without actually doing anything about it is just going to make your argument look utterly redundant. If it's your itch, either you scratch it or you persuade someone who can. That person will certainly not be me. There has been more than enough time already. I mean, even GnuCash migrated to Gtk+2.0 in time. Bit rot has no respect for good intentions, or wishful thinking. IMHO, Debian is not about collecting ancient software just because it is free software. A package must deserve a place in the archive or it should be removed. Personally, I think there are plenty of alternatives to xmms - I haven't missed it. If you think different, it is up to you to step up and do something with the codebase. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpfUn0Z7UJkb.pgp Description: PGP signature
Packages still depending on GTK+ 1.2
Hi, GTK+ 1.2 has been deprecated upstream for 6 years. There is no security support for it, and no new applications using it have been out for quite a long time as well. I think it is more than time to remove it from the archive. Of course, this can only be done after we have dealt with the reverse dependencies. For them, there are not many solutions: * Look for alternatives using GTK+ 2.x. For most utilities and games, they already exist, whether already in the archive or somewhere else ready to be packaged. * Port to GTK+ 2.x. Depending on the application, this can be a trivial or very large task, and it requires a bit of motivation. * Simply drop the application from the archive. Here is a first list of packages that could either be removed right now because they seem to have replacements, or updated with little work. If there are no objections, I think we should ask for removal of all of those which don’t have a GTK+ 2 version. Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] shaketracker = we have other sequencers in the archive swami = upstream is currently porting it to GTK+ 2 Marc Dequènes (Duck) [EMAIL PROTECTED] worlded = no upstream news for 4 years, we have better such games in the archive Jari Aalto [EMAIL PROTECTED] gcrontab = gnome-schedule Russ Allbery [EMAIL PROTECTED] gtimer = hamster-applet, gnotime Ben Armstrong [EMAIL PROTECTED] snowflake = just a toy Ernesto Nadir Crespo Avila [EMAIL PROTECTED] xwhois = gnome-nettool Bradley Bell [EMAIL PROTECTED] gtkmm Jon Bernard [EMAIL PROTECTED] e16menuedit = we don’t ship E16 anymore Adrian Bridgett [EMAIL PROTECTED] gato = gnome-schedule Marc 'HE' Brockschmidt [EMAIL PROTECTED] wmclockmon = Yet Another WindowMaker Applet Mark Brown [EMAIL PROTECTED] powertweak = Is that still relevant with modern power management policies? Daniel Burrows [EMAIL PROTECTED] xarchon = Unmaintained upstream for 5 years, we’re not lacking games xpuyopuyo = flobopuyo, cuyo… Ross Burton [EMAIL PROTECTED] gtk-engines-lighthouseblue Patryk Cisek [EMAIL PROTECTED] kadu = pidgin Debian Electronics Team [EMAIL PROTECTED] gwave = gtkwave Debian Games Team [EMAIL PROTECTED] lmemory = gcompris ? Tim Dijkstra [EMAIL PROTECTED] digitaldj = prokyon3 Randall Donald [EMAIL PROTECTED] gradio = gnomeradio Peter Eisentraut [EMAIL PROTECTED] pinentry = just need to disable the GTK+ 1.2 build Rene Engelhard [EMAIL PROTECTED] aria = gwget manedit = gmanedit Devid Filoni [EMAIL PROTECTED] dillo = there is a new upstream based on FLTK Bdale Garbee [EMAIL PROTECTED] predict (U) Debian QA Group [EMAIL PROTECTED] gnome-libs gtkfontsel gtkglarea imlib netdude sqlrelay stegdetect = QA-maintained packages should be removed as soon as they don’t have remaining rdeps Steinar H. Gunderson [EMAIL PROTECTED] amoeba = just a toy, and we have rss-glx Wartan Hachaturow [EMAIL PROTECTED] grpn = calcoo John Hasler [EMAIL PROTECTED] gpppon = gnome-ppp Uwe Hermann [EMAIL PROTECTED] cccd = we have so many CD players that I won’t list them powershell = gnome-terminal, xfterm… Alberto Gonzalez Iniesta [EMAIL PROTECTED] gqcam = cheese… Joerg Jaspert [EMAIL PROTECTED] xbindkeys-config = I think we have quite a number of key-event managers already Steffen Joeris [EMAIL PROTECTED] xoscope = extace Matthew Johnson [EMAIL PROTECTED] gbib = pybliographer ? Daniel Kobras [EMAIL PROTECTED] libdv = we just need to stop building libdv-bin Alexander Kotelnikov [EMAIL PROTECTED] fvwm (U) Antonin Kral [EMAIL PROTECTED] gtkguitune = lingot Noèl Köthe [EMAIL PROTECTED] mbrowse = tkmib + at least 2 online services doing the same Wesley J. Landaker [EMAIL PROTECTED] gwave (U) Chris Lawrence [EMAIL PROTECTED] gnome-lokkit = so many iptables frontends… Ron Lee [EMAIL PROTECTED] wxwindows2.4 = no remaining rdeps Jacob Luna Lundberg [EMAIL PROTECTED] xscorch = atanks, scorched3d Eduardo Marcel Macan [EMAIL PROTECTED] vertex = blender ? Camm Maguire [EMAIL PROTECTED] codebreaker = gnome-mastermind OHURA Makoto [EMAIL PROTECTED] tex-guy = xgdvi can be replaced by evince and many others xemacs21 = maybe we need to wait for emacs23 Paul Mangan [EMAIL PROTECTED] sylpheed-gtk1 (U) Bart Martens [EMAIL PROTECTED] qiv = yay, an image viewer GOTO Masanori [EMAIL PROTECTED] lm-batmon = yay, a battery monitor Hamish Moffatt [EMAIL PROTECTED] guile-gtk-1.2 gwave (U) Ricardo Mones [EMAIL PROTECTED] sylpheed-gtk1 = sylpheed-claws Stephen M Moraco [EMAIL PROTECTED] karpski = wireshark Ryan Murray [EMAIL PROTECTED] gdk-pixbuf Francesco Namuri [EMAIL PROTECTED] lopster = did you know that Napster was shut down? Kari Pahula [EMAIL PROTECTED] crossfire-client = just need to disable the GTK+ 1.2 build Drew Parsons
Re: Packages still depending on GTK+ 1.2
On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: Jon Bernard [EMAIL PROTECTED] e16menuedit = we don’t ship E16 anymore packages.debian.org says otherwise. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Packages still depending on GTK+ 1.2
Josselin Mouette wrote: snip Debian Games Team [EMAIL PROTECTED] lmemory = gcompris ? I'll take a look at this one. snip Debian QA Group [EMAIL PROTECTED] gnome-libs gtkfontsel gtkglarea imlib netdude sqlrelay stegdetect = QA-maintained packages should be removed as soon as they don’t have remaining rdeps I will look at this as well since I'm on an RM:/proposed RM kick. I assume this is more of a Lenny+1 goal? Thanks, 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
Barry deFreese wrote: OK, I have looked at several of these and man what a mess. snip Debian QA Group [EMAIL PROTECTED] gnome-libs Orphaned but obviously tons of r(b)depends. gtkfontsel Orphaned but a fairly significant popcon. I can't find new upstream source. Could probably be ported or RM:d. gtkglarea Orphaned and I can't find any upstream source yet but again lots of r(b)depends. imlib Orphaned and LOTS of r(b)depends. netdude ITA'd. There is a new upstream available. I've pinged the ITAer to see if the new upstream is GTK 2.0. sqlrelay Some of the binaries have decent popcons. We could probably either port sqlrelay-config-gtk or just remove that binary for now. stegdetect RM: filed. Is this really feasible? How many people are going to work on dead packages? Or if we RM: the lot of them, how many users are we pissing off? Thanks, 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 Friday 05 December 2008 13:06, Josselin Mouette wrote: Paul Mangan [EMAIL PROTECTED] sylpheed-gtk1 (U) ... Ricardo Mones [EMAIL PROTECTED] sylpheed-gtk1 = sylpheed-claws sylpheed-gtk1 should be replaced by sylpheed. sylpheed-claws (now claws-mail) is a fork. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On 05/12/2008, at 21.11, Barry deFreese wrote: Is this really feasible? How many people are going to work on dead packages? Or if we RM: the lot of them, how many users are we pissing off? There are several useful science programs that still make use of GTK+ 1.2, one is a very useful chemistry program, GAMGI, which is in the new queue and on its way into unstable. The other is coot, a widespread application for macromolecular crystallography. Please don't remove GTK+ 1.2. There are still upstream authors, especially in science who use GTK+ 1.2 and who don't bother revising their programs from the wisdom: if it ain't broke don't fix it. 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
Josselin Mouette [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] gtimer = hamster-applet, gnotime My intention is to request removal of gtimer when there's a consensus that GTK+ 1.2 is going away. The package has been RFA for years without a nibble, I haven't used it personally in about five years, and I'm only still maintaining it because I know a few people use it and it hasn't required much effort to keep it mostly up to snuff. But the resources to port it to a new version of GTK just aren't there, and it's dead upstream. If it's now time to get rid of GTK+ 1.2, I can file a removal request for it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Russ Allbery wrote: Josselin Mouette [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] gtimer = hamster-applet, gnotime My intention is to request removal of gtimer when there's a consensus that GTK+ 1.2 is going away. The package has been RFA for years without a nibble, I haven't used it personally in about five years, and I'm only still maintaining it because I know a few people use it and it hasn't required much effort to keep it mostly up to snuff. But the resources to port it to a new version of GTK just aren't there, and it's dead upstream. If it's now time to get rid of GTK+ 1.2, I can file a removal request for it. I think there is a consensus to get rid of GTK+ 1.2, but we didn't manage to do it for Lenny, although we made some progress. Personally I would like to get rid of it before Squeeze preferably with ported applications or alternatives. Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: Mark Brown [EMAIL PROTECTED] powertweak = Is that still relevant with modern power management policies? It's nothing to do with power management. I'd rather let it stay until lenny is released, though if it were the only thing keeping GTK 1.2 in it should go. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Hi, On Fri, Dec 05, 2008 at 10:41:52PM +0100, Morten Kjeldgaard wrote: On 05/12/2008, at 21.11, Barry deFreese wrote: Is this really feasible? How many people are going to work on dead packages? Or if we RM: the lot of them, how many users are we pissing off? There are several useful science programs that still make use of GTK+ 1.2, one is a very useful chemistry program, GAMGI, which is in the new queue and on its way into unstable. AFAICT, gamgi is using GTK-2.0. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
On 06/12/2008, at 00.09, Michael Banck wrote: There are several useful science programs that still make use of GTK+ 1.2, one is a very useful chemistry program, GAMGI, which is in the new queue and on its way into unstable. AFAICT, gamgi is using GTK-2.0. Yes you are right, gamgi uses GTK-2.0 as of March this year. I was quoting from (volatile, apparently) memory. 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. 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
Le vendredi 05 décembre 2008 à 13:19 -0500, James Vega a écrit : On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: Jon Bernard [EMAIL PROTECTED] e16menuedit = we don’t ship E16 anymore packages.debian.org says otherwise. Ah right, it was renamed. Anyway, there is e16menuedit2 which uses GTK+ 2.x. Thanks, -- .''`. : :' : 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
Le vendredi 05 décembre 2008 à 15:11 -0500, Barry deFreese a écrit : gtkfontsel Orphaned but a fairly significant popcon. I can't find new upstream source. Could probably be ported or RM:d. The notion of X fonts is simply losing its meaning now that most if not all toolkits are using Xft2. IIUC their support will be dropped from the X server some time in the future. imlib Orphaned and LOTS of r(b)depends. I wonder how many exploitable security issues there are in this one. -- .''`. : :' : 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
Le vendredi 05 décembre 2008 à 22:49 +, Mark Brown a écrit : On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: Mark Brown [EMAIL PROTECTED] powertweak = Is that still relevant with modern power management policies? It's nothing to do with power management. I'd rather let it stay until lenny is released, though if it were the only thing keeping GTK 1.2 in it should go. Does it even work? The description says it needs a /dev/cpu/ tree. -- .''`. : :' : 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
Barry deFreese wrote: [...] stegdetect RM: filed. Why isn't just the xsetg package dropped? stegdetect is a CLI app; only xsteg uses GTK+ Cheers, /me who has stegdetect installed and keeps it around to time by time try to find something that just isn't there -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages still depending on GTK+ 1.2
Raphael Geissert wrote: Barry deFreese wrote: [...] stegdetect RM: filed. Why isn't just the xsetg package dropped? stegdetect is a CLI app; only xsteg uses GTK+ Cheers, /me who has stegdetect installed and keeps it around to time by time try to find something that just isn't there Feel free to adopt it then. :) 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
Josselin Mouette wrote: [...] Joerg Jaspert [EMAIL PROTECTED] xbindkeys-config = I think we have quite a number of key-event managers already And is prone to buffer overflow attacks (only reported one atm, though). Josip Rodin [EMAIL PROTECTED] [...] gentoo The maint docs will need an update if gentoo is removed (yay! Debian will remove its competition from the archive :) 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. Christoph Martin [EMAIL PROTECTED] gtalk w00t, didn't know Google's IM was already ported (JK). P.S. thanks for working on it, never really found time to go through that list (/me wanted to just RM libgtk and its rdeps). Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
