Re: New ftpteam member
Stefano Zacchiroli wrote: > On Tue, Dec 09, 2008 at 12:23:04AM +0100, Joerg Jaspert wrote: >>> And they said that there was no German cabal? :P >> Want to volunteer and possibly join too, to get some non-german >> blood in? > I'm disappointed: I expected a reply in German :-P Das ist etwas später im Auswahlverfahren. 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: New ftpteam member
On Tue, 9 Dec 2008, Stefano Zacchiroli wrote: On Tue, Dec 09, 2008 at 12:23:04AM +0100, Joerg Jaspert wrote: And they said that there was no German cabal? :P Want to volunteer and possibly join too, to get some non-german blood in? I'm disappointed: I expected a reply in German :-P Das kommt mir spanisch vor. Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY
Package: wnpp Severity: wishlist Owner: Damyan Ivanov <[EMAIL PROTECTED]> * Package name: libio-pager-perl Version : 0.05 Upstream Author : Jerrad Pierce <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/IO-Pager/ * License : other - Thou shalt not claim ownership of unmodified materials. - Thou shalt not claim whole ownership of modified materials. - Thou shalt grant the indemnity of the provider of materials. - Thou shalt use and dispense freely without other restrictions. Programming Lang: Perl Description : pipe output to a pager if destination is a TTY IO::Pager hijacks normal output to a given file handle and pipes it through a pager program if the file handle is connected with a terminal. This package is a dependency of clive 2 and will be maintained under pkg-perl umbrella. -- 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]
Bug#508262: ITP: libcatalyst-component-instancepercontext-perl -- Moose role to create only one instance of component per context
Package: wnpp Severity: wishlist Owner: Brian Cassidy <[EMAIL PROTECTED]> * Package name: libcatalyst-component-instancepercontext-perl Version : 0.001001 Upstream Author : Guillermo Roditi (groditi) <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Catalyst-Component-InstancePerContext/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Moose role to create only one instance of component per context Catalyst::Component::InstancePerContext provides a simple reusable component for per-request object instantiation. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 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: New ftpteam member
Le Tue, Dec 09, 2008 at 12:23:04AM +0100, Joerg Jaspert a écrit : > > Want to volunteer and possibly join too, to get some non-german blood in? Hi all, I offer my help for the copyright checking. 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
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: ITP: autodie -- Replace functions with ones that succeed or die with lexical scope
Speaking about scope, name collision, etc.… Jeremiah Foster <[EMAIL PROTECTED]> (09/12/2008): > Package: wnpp > Severity: wishlist > Owner: "Jeremiah C. Foster" <[EMAIL PROTECTED]> > > > * Package name: libautodie-perl that is the name that should be in the first part of your ITP subject. Ditto for the other ITP. Mraw, KiBi. signature.asc Description: Digital signature
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
Bug#508273: ITP: libcatalyst-controller-html-formfu-perl -- Catalyst integration for HTML::FormFu
Package: wnpp Severity: wishlist Owner: Brian Cassidy <[EMAIL PROTECTED]> * Package name: libcatalyst-controller-html-formfu-perl Version : 0.03007 Upstream Author : Carl Franks <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Catalyst-Controller-HTML-FormFu/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : Catalyst integration for HTML::FormFu By subclassing Catalyst::Controller::HTML::FormFu, you can easily load forms from external configuration files as well as integrate with your existing models and I18N data. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 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: ITP: IPC::System::Simple -- Run commands simply, with detailed diagnostics
On Tue, 09 Dec 2008, Jeremiah Foster wrote: > * Package name: libipc-system-simple-perl > Calling Perl's in-built system() function is easy, determining if it > was successful is hard. Let's face it, $? isn't the nicest variable in > the world to play with, and even if you do check it, producing a well- > formatted error string takes a lot of work. Do you have a description that is suitable for the package also? -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- 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. > > > 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: Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY
On Tue, Dec 09, 2008 at 11:19:42AM +0200, Damyan Ivanov wrote: * Package name: libio-pager-perl Version : 0.05 Upstream Author : Jerrad Pierce <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/IO-Pager/ * License : other - Thou shalt not claim ownership of unmodified materials. - Thou shalt not claim whole ownership of modified materials. - Thou shalt grant the indemnity of the provider of materials. This may be a problem. I know in the past, clauses requiring indemnification were not allowed. CCing debian-legal for discussion. Please follow up there. - Thou shalt use and dispense freely without other restrictions. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital 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
Bug#508311: ITP: maven-archiver -- Maven Archiver
Package: wnpp Severity: wishlist Owner: Torsten Werner <[EMAIL PROTECTED]> * Package name: maven-archiver Version : 2.3 Upstream Author : Apache Software Foundation * URL : http://maven.apache.org/shared/maven-archiver * License : Apache-2.0 Programming Lang: Java Description : Maven Archiver Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. . Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with: . * Making the build process easy * Providing a uniform build system * Providing quality project information * Providing guidelines for best practices development * Allowing transparent migration to new features . The Maven Archiver is mainly used by Maven plugins to handle packaging. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#508311: ITP: maven-archiver -- Maven Archiver
Torsten Werner <[EMAIL PROTECTED]> (09/12/2008): > * Package name: maven-archiver > Description : Maven Archiver No kidding‽ Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#508311: ITP: maven-archiver -- Maven Archiver
On Tue, Dec 9, 2008 at 11:07 PM, Cyril Brulebois <[EMAIL PROTECTED]> wrote: > Torsten Werner <[EMAIL PROTECTED]> (09/12/2008): >> * Package name: maven-archiver >> Description : Maven Archiver > > No kidding‽ Do you have any better description? The title of the homepage is 'About Maven Archiver'. Cheers, Torsten
Bug#508316: ITP: maven-jar-plugin -- Maven Jar plugin
Package: wnpp Severity: wishlist Owner: Torsten Werner <[EMAIL PROTECTED]> * Package name: maven-jar-plugin Version : 2.2 Upstream Author : Apache Software Foundation * URL : http://maven.apache.org/plugins/maven-jar-plugin/ * License : Apache-2.0 Programming Lang: Java Description : Maven Jar plugin Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. . Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with: . * Making the build process easy * Providing a uniform build system * Providing quality project information * Providing guidelines for best practices development * Allowing transparent migration to new features . This plugin provides the capability to build and sign jars. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY
On Tue, 9 Dec 2008 19:21:18 + brian m. carlson wrote: > On Tue, Dec 09, 2008 at 11:19:42AM +0200, Damyan Ivanov wrote: > >* Package name: libio-pager-perl > > Version : 0.05 > > Upstream Author : Jerrad Pierce <[EMAIL PROTECTED]> > >* URL : http://search.cpan.org/dist/IO-Pager/ > >* License : other > > - Thou shalt not claim ownership of unmodified materials. > > - Thou shalt not claim whole ownership of modified materials. > > - Thou shalt grant the indemnity of the provider of materials. > > This may be a problem. I know in the past, clauses requiring > indemnification were not allowed. CCing debian-legal for discussion. > Please follow up there. > > > - Thou shalt use and dispense freely without other restrictions. If those four "Thou shalt" sentences are the whole license text, I see other issues. There's no clear permission to distribute (DFSG#1): if "dispense" may be assumed to mean "distribute", the fourth sentence sounds like an obligation, rather than like a grant of permission. Am I *compelled* to use and distribute libio-pager-perl?!? There's no clear permission to modify and distribute modified versions (DFSG#3). Moreover, the license text does not seem to be drafted in a legally sound manner... Is this package planned to be uploaded to main or contrib? Or is it meant for the non-free archive? As usual, my disclaimers apply: IANAL, TINLA, IANADD, TINASOTODP. P.S.: why are we refraining from Cc:ing the bug address? -- On some search engines, searching for my nickname AND "nano-documents" may lead you to my website... . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpr6HVE6yhLb.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]
symlinks bug: fixed upstream
With reference to: http://lists.debian.org/debian-devel/2008/08/msg00347.html mtx-changer.Adic-Scalar-24 has been fixed in the Bacula repository. Committed revision 8134. NOTE: the code wasn't part of Bacula proper. It's one of the examples we supply. http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/bacula/examples/autochangers/mtx-changer.Adic-Scalar-24?r1=2805&r2=8134 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
