On Sun, Dec 04, 2005 at 07:11:08PM +0100, Martin Zobel-Helas wrote: > Hi, > > What could be done IMHO is to backport the necessary changes of > gtk-gnutella that it can again connect to the networks. But just > compiling a newer version of it for sarge is not an option for volatile. Why? Please explain why that isn't an option? > That's what backports.org is for. From volatile.debian.net: "Some packages aim at fast moving targets ..." Which fits gtk-gnutella perfectly. From volatile.debian.net: "acceptance rules ..." In this case gtk-gnutella meets all the acceptance rules. The "changes to stable programs that are necessary to keep them functional" in this case are an upgrade is required. This isn't something new or different, both clamav and jwhois have had newer upstream versions. > We might accept gtk-gnutella for volatile-sloopy, but not in the current > state of the package. Well, apart from never hearing about volatile-sloopy (perhaps you mean sloppy?) what exactly is wrong with the package. Both Andreas and yourself have aluded to some deep-seated packaging issue. What is the this perceived packaging problem? > BTW, if you, dear reader of firstname.lastname@example.org, think our > decision is wrong, try to convince us. It's not only up to Andi and me > to decide what goes in and what not, but currently it seems it is only > Andi and me inspecting the packages. Sure we have the last word, as we > need to accept it on the ftp-server, but we only humans and might make > mistakes. Speak with us, only that gives us the possibility to get a > clue what our users whould like to have on volatile. Well, gtk-gnutella is more popular than jwhois among our userbase if that counts for anything. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --"
Description: Digital signature