Stop send E-mails to me!!!!!!!
debian-devel-digest-request@lists.debian.org wrote:
>
> Subject:
>
> debian-devel-digest Digest Volume 99 : Issue 19
>
> Today's Topics:
> Re: Incoming mirror? [ Adrian Bridgett <adrian.bridgett@ze ]
> Re: Suggestion: Skip Slink! [ John Goerzen <jgoerzen@complete.org ]
> Re: Debian Weekly News - 29 Dec 1998 [ Hamish Moffatt <hamish@debian.org> ]
> Re: /pub/incoming/debian-non-US not [ Christoph Martin <martin@verwaltung ]
> Re: Proposal: Adding more architectu [ Joey Hess <joey@kitenet.net> ]
> Re: Suggestion: Skip Slink! [ Joey Hess <joey@kitenet.net> ]
> Re: Suggestion: Skip Slink! [ Joey Hess <joey@kitenet.net> ]
> Re: Suggestion: Skip Slink! [ Joey Hess <joey@kitenet.net> ]
> Re: libpng & gnome & slink [ Vincent Renardias <vincent@ldsol.co ]
> Re: libpng & gnome & slink [ Shaleh <shaleh@livenet.net> ]
> Re: libpng & gnome & slink [ Vincent Renardias <vincent@ldsol.co ]
> Overall Unmet dependencies [ Jason Gunthorpe <jgg@ualberta.ca> ]
> RE: list archiving software [ Darren Benham <gecko@benham.net> ]
> Re: Overall Unmet dependencies [ Vincent Renardias <vincent@ldsol.co ]
> Re: Overall Unmet dependencies [ Joey Hess <joey@kitenet.net> ]
> Re: Adopting dpkg-ftp [ Yann Dirson <ydirson@mygale.org> ]
> Re: Adopting dpkg-ftp [ Jason Gunthorpe <jgg@ualberta.ca> ]
> Re: list archiving software [ Darren Benham <gecko@benham.net> ]
> Re: Overall Unmet dependencies [ Joseph Carter <knghtbrd@debian.org> ]
>
> ---------------------------------------------------------------
>
> Subject: Re: Incoming mirror?
> Date: Wed, 6 Jan 1999 20:05:49 +0000
> From: Adrian Bridgett <adrian.bridgett@zetnet.co.uk>
> To: debian-devel@lists.debian.org
>
> On Wed, Jan 06, 1999 at 10:19:51AM +1100, Craig Sanders wrote:
> > the incoming mirror at llug.sep.bnl.gov vanished a few weeks ago...anyone
> > know where another one is?
> >
> > i'd like to mirror incoming locally again...it's often very useful.
>
> Here's the list I use (the top one usually). Many thanks to all who provide
> these (are they in the mirrors.html file (the new one that _didn't_ have a
> link from www.debian.org a few weeks ago).
>
> ftp://ftp.lh.umu.se/pub/linux/debian-Incoming
> ftp://ftp.fuller.edu/debian-incoming
> ftp://llug.sep.bnl.gov/pub/debian/Incoming
> ftp://rulcmc.leidenuniv.nl/debian/incoming
> ftp://os.inf.tu-dresden.de//debian/Incoming
>
> Adrian
>
> email: adrian.bridgett@zetnet.co.uk, http://www.poboxes.com/adrian.bridgett
> Windows NT - Unix in beta-testing. PGP key available on public key servers
> Avoid tiresome goat sacrifices -=- use Debian Linux http://www.debian.org
>
> ---------------------------------------------------------------
>
> Subject: Re: Suggestion: Skip Slink!
> Date: Wed, 6 Jan 1999 14:57:42 -0600
> From: John Goerzen <jgoerzen@complete.org>
> To: Avery Pennarun <apenwarr@worldvisions.ca>
> CC: debian-devel@lists.debian.org
>
> On Wed, Jan 06, 1999 at 03:12:47PM -0500, Avery Pennarun wrote:
>
> > For Red Hat, it would be possible to make RH5.1 for i386 and sparc stable at
> > the same time, simply by ordering the right number of employees to work on
> > each port. They favour i386 for purely profit and marketing reasons,
> > because i386 is more popular. Don't jump on me for saying that. It's true.
>
> Of course, that is correct.
>
> > Debian doesn't do things for public popularity, or for profit. But we also
> > don't have a management team. You can't order i386 developers to work on
> > the sparc version, and as a side-effect of i386 being popular, there are a
> > lot more i386 developers than sparc developers. Therefore i386 gets newer
> > packages and faster bugfixes, and that's the way it is.
>
> I'm not saying that i386 developers ought to be ordered to work on Sparc.
> To do so would be silly. I'm also not saying that there is necessarily a
> problem with most packages showing up first on the i386 distribution; this
> effects unstable only, no big deal there. Porters will get around to it
> eventually.
>
> What I am complaining about is that there are certain things that are either
> being done or suggested that relegate other ports to a second-class status.
>
> > You can, of course, still release the i386 and sparc ports at the same time,
> > but that's because i386 is later, not because sparc is earlier. That's a
> > failure, not an improvement. I can see absolutely no advantage in such a
> > delay.
>
> It's not the Sparc's fault that it is not truly frozen yet.
>
> Further, at freeze time, all ports "should" be at the same spot anyway, or
> very nearly so.
>
> It's when people start suggesting that we don't release one port simply
> because its FTP directory was not frozen at the same time as i386, and
> therefore hasn't had a chance to catch up yet, that really gets on my
> nerves.
>
> --
> John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org |
> Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org |
> ----------------------------------------------------------------------------+
> Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
>
> ---------------------------------------------------------------
>
> Subject: Re: Debian Weekly News - 29 Dec 1998 to 5 Jan 1999
> Date: Thu, 7 Jan 1999 08:18:08 +1100
> From: Hamish Moffatt <hamish@debian.org>
> To: Debian developers list <debian-devel@lists.debian.org>
>
> On Wed, Jan 06, 1999 at 03:04:33PM +0000, Julian Gilbey wrote:
> > I think your Debian weekly news bulletin is a great idea -- I would
> > have missed the qmail -> exim announcement since I often don't read
> > every mail on -private. Suggestion to whoever: announcements like
> > that should also be posted on -devel-announce or flagged in the
> > subject line in -private.
>
> Yes, now that I've just noticed I posted to -devel-announce twice
> by mistake.
>
> Sorry folks.
>
> Hamish
> --
> Hamish Moffatt VK3TYD hamish@debian.org, hamish@rising.com.au
> Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
> CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
>
> ---------------------------------------------------------------
>
> Subject: Re: /pub/incoming/debian-non-US not writable
> Date: Wed, 6 Jan 1999 22:21:36 +0100 (MET)
> From: Christoph Martin <martin@verwaltung.uni-mainz.de>
> To: Christoph Martin <martin@verwaltung.uni-mainz.de>
> CC: non-us-ftp@dresden.de.debian.org, debian-devel@lists.debian.org
>
> Christoph Martin writes:
> >
> > I tried to upload a new version of ssltelnet, but the upload directory
> > on nonus.debian.org is not writable.
>
> now it's group writable but not user writable. The ownership of the
> directory is different from the ownership of the created files. So one
> can not overwrite, rename or delete ones own files.
>
> My upload of ssltelnet failed and now I can't overwrite the corrupted
> files.
>
> Christoph
>
> ---------------------------------------------------------------
>
> Subject: Re: Proposal: Adding more architecture options to dpkg (was: Re: Adding Hurd architecture/os to dpkg and packaging scripts.)
> Date: Wed, 6 Jan 1999 13:17:24 -0800
> From: Joey Hess <joey@kitenet.net>
> To: Steve Dunham <dunham@cse.msu.edu>
> CC: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>,
> Martin Mitchell <martin@debian.org>, debian-devel@lists.debian.org,
> dpkg-maint@chiark.greenend.org.uk
>
> Steve Dunham wrote:
> > When you make these changes to dpkg, try to find a way to deal with
> > platforms that handle two different architectures. (e.g. UltraSparc
> > machines handle sparc and sparc64, intel machines handle i386 and the
> > proposed i586 distributions.) It would be nice to build and install
> > packages for both architectures on these machines.
> >
> > I have "sparc" Debian installed on my Ultra5, and successfully compile
> > packages for the "sparc" architecture - in fact, the tools to build
> > userland code for "sparc64" are not ready and will not be ready for
> > quite a while. (And, even then, we'd probably want a mixture of
> > packages to guarantee system stability.)
>
> I have a patch to dpkg that does this. I think I submitted it as a wishlist
> bug. It makes dpkg read a new file, /etc/dpkg/architectures, which has a
> format like:
>
> i386: i386 all pentium
> ultrapsparc: sparc all sparc64
>
> --
> see shy jo
>
> ---------------------------------------------------------------
>
> Subject: Re: Suggestion: Skip Slink!
> Date: Wed, 6 Jan 1999 13:27:03 -0800
> From: Joey Hess <joey@kitenet.net>
> To: "Ivan E. Moore II" <rkrusty@tdyc.com>
> CC: debian-devel@lists.debian.org
>
> Ivan E. Moore II wrote:
> > I personally think we need to treat each port differently. As
> > each one will have it's own issues. Yes, the source distro is
> > different and contains all of them...but maybe that needs
> > to be re-thunk (uhh) on how it should be handled. But I don't
> > think holding up the release of other ports due to one port
> > not being ready is a solution. That would definatly cause
> > Debian to get behind at some point in time or another.
>
> Here's a solutuion to the source distribution problem. Whenever we add a new
> release to debian, we could increment the release number. Ie, if we release
> just i386 as debian 2.1r1, then when m68k is ready, we bump the version up to
> debian 2.1r2. This means we release a new source cd as well (and new i386
> cd's, which will have minimal changes).
>
> I doubt this would mean much more frequent changes to debian's revision
> number than we have now - we have to change the revision number occasionally
> for security fixes anyway.
>
> --
> see shy jo
>
> ---------------------------------------------------------------
>
> Subject: Re: Suggestion: Skip Slink!
> Date: Wed, 6 Jan 1999 13:32:33 -0800
> From: Joey Hess <joey@kitenet.net>
> To: Avery Pennarun <apenwarr@worldvisions.ca>
> CC: John Goerzen <jgoerzen@complete.org>, debian-devel@lists.debian.org
>
> Avery Pennarun wrote:
> > However, if slink/sparc is released with a few changes after slink/i386,
> > there's nothing stopping the i386 people from rebuilding their packages with
> > sparc's changes in order to catch up. We just call that Debian 2.1r2, and
> > sparc never made a 2.1r1 release. If I'm an admin concerned with
> > consistency, I stayed with hamm until all my required arches were stable.
>
> I agree (came up with the same idea independantly, in fact).
>
> --
> see shy jo
>
> ---------------------------------------------------------------
>
> Subject: Re: Suggestion: Skip Slink!
> Date: Wed, 6 Jan 1999 13:33:29 -0800
> From: Joey Hess <joey@kitenet.net>
> To: John Goerzen <jgoerzen@complete.org>
> CC: Avery Pennarun <apenwarr@worldvisions.ca>, debian-devel@lists.debian.org
>
> John Goerzen wrote:
> > > However, if slink/sparc is released with a few changes after slink/i386,
> > > there's nothing stopping the i386 people from rebuilding their packages with
> > > sparc's changes in order to catch up. We just call that Debian 2.1r2, and
> > > sparc never made a 2.1r1 release. If I'm an admin concerned with
> > > consistency, I stayed with hamm until all my required arches were stable.
> >
> > This logic only works if you happen to use FTP.
>
> How so?
>
> When debian 2.1r1 is released, new source and binary cd's would be made.
>
> --
> see shy jo
>
> ---------------------------------------------------------------
>
> Subject: Re: libpng & gnome & slink
> Date: Wed, 6 Jan 1999 23:44:03 +0100 (CET)
> From: Vincent Renardias <vincent@ldsol.com>
> To: Andreas Tille <tille@physik.uni-halle.de>
> CC: Brian Almeida <bma@debian.org>, matt.nottingham@virgin.net,
> Debian Devel ML <debian-devel@lists.debian.org>
>
> On Wed, 6 Jan 1999, Andreas Tille wrote:
>
> > On Wed, 6 Jan 1999, Brian Almeida wrote:
> >
> > > Because the Imlib maintainer (me) has a permanent hold on those packages
> > > in dselect >:)
> > Me too!!
> >
> > > Yes. I second this. RedHat and others have already moved back. Let's not
> > > break all imlib and gnome apps :p
> > Don't let all users set hold on the older versions and downgrade to
> > a working version!
>
> I've uploaded in my account on master (~vincent) a new version of libpng2
> that doesn't seem to have the bug, and fools Imlib's configuration
> pretending it's libpng-1.0.1.
> Can you try to see if it fixes your problem?
>
> Cordialement,
>
> --
> - Vincent RENARDIAS vincent@{{ldsol,pipo}.com,{debian,openhardware}.org} -
> - Debian/GNU Linux: http://www.openhardware.org Logiciels du soleil: -
> - http://www.fr.debian.org Open Hardware: http://www.ldsol.com -
> ---------------------------------------------------------------------------
> -"Microsoft est ŕ l'informatique ce que le grumeau est ŕ la crépe..." -
>
> ---------------------------------------------------------------
>
> Subject: Re: libpng & gnome & slink
> Date: Wed, 06 Jan 1999 17:17:27 -0500 (EST)
> From: Shaleh <shaleh@livenet.net>
> To: Vincent Renardias <vincent@ldsol.com>
> CC: Debian Devel ML <debian-devel@lists.debian.org>,
> Debian Devel ML <debian-devel@lists.debian.org>,
> Brian Almeida <bma@debian.org>
>
> > I've uploaded in my account on master (~vincent) a new version of libpng2
> > that doesn't seem to have the bug, and fools Imlib's configuration
> > pretending it's libpng-1.0.1.
> > Can you try to see if it fixes your problem?
> >
> > Cordialement,
> >
>
> I have installed this version from your directory. SUCCESS! No more weird
> lines in the background. Eterm seems happy with it. Any GNOME or E users care
> to respond?
>
> ---------------------------------------------------------------
>
> Subject: Re: libpng & gnome & slink
> Date: Thu, 7 Jan 1999 00:31:58 +0100 (CET)
> From: Vincent Renardias <vincent@ldsol.com>
> To: Shaleh <shaleh@livenet.net>
> CC: Debian Devel ML <debian-devel@lists.debian.org>
>
> On Wed, 6 Jan 1999, Shaleh wrote:
>
> > > I've uploaded in my account on master (~vincent) a new version of libpng2
> > > that doesn't seem to have the bug, and fools Imlib's configuration
> > > pretending it's libpng-1.0.1.
> > > Can you try to see if it fixes your problem?
> > >
> > > Cordialement,
> > >
> >
> > I have installed this version from your directory. SUCCESS! No more weird
> > lines in the background. Eterm seems happy with it. Any GNOME or E users care
> > to respond?
>
> Ok, next "problem":
>
> Some PNG images, for example
> /var/www/usr/lib/latex2html/icons/up_motif_gr.png <Insert here comment
> about the inapropriate location of this file installed by latex2html> are
> displayed _correctly_ with xv, while it is _not_ with ee.
> So, there still may be a bug in ee or Imlib.
>
> Cordialement,
>
> --
> - Vincent RENARDIAS vincent@{{ldsol,pipo}.com,{debian,openhardware}.org} -
> - Debian/GNU Linux: http://www.openhardware.org Logiciels du soleil: -
> - http://www.fr.debian.org Open Hardware: http://www.ldsol.com -
> ---------------------------------------------------------------------------
> -"Microsoft est ŕ l'informatique ce que le grumeau est ŕ la crépe..." -
>
> ---------------------------------------------------------------
>
> Subject: Overall Unmet dependencies
> Date: Wed, 6 Jan 1999 15:39:52 -0700 (MST)
> From: Jason Gunthorpe <jgg@ualberta.ca>
> To: Debian Developers <debian-devel@lists.debian.org>
> CC: debian-testing@lists.debian.org
>
> I was bored so here is an interesting report for you all. The packages
> listed here CANNOT be installed but are included in slink, they should
> probably be removed or fixed ASAP.
>
> Wakko{jgg}~/work/apt/apt-pkg#apt-cache unmet -i
> Package apache-common version 1.3.0+1.19-1 has an unmet dep:
> Depends: libssl08
> Package doom-musserver version 1.0-7 has an unmet dep:
> Depends: doom (>= 1.10-11)
> Package afbackup-i version 3.1beta1-1 has an unmet dep:
> Depends: libssl08
> Package afbackup-client-i version 3.1beta1-1 has an unmet dep:
> Depends: libssl08
> Package vrwave version 0.9-1 has an unmet dep:
> Depends: mesag2 (>= 2.6)
> Package metro-motif-aout version 2.0-2 has an unmet dep:
> Depends: xcompat (>= 3.1.2-4)
> Package ktop version 0.9.7-3 has an unmet dep:
> Depends: kdebase
> Depends: kdelibs0g-dev
> Depends: kdelibs0g (>= 2:980710)
> Package libfltk-dev version 0.99-1.1 has an unmet dep:
> Depends: libstdc++2.8-dev (>= 2.90.26-1)
> Package qtscape version 5.0.19980408-1 has an unmet dep:
> Depends: qt1-snapshot (>= 1.39.19980414-1)
> Package pppload version 1.0-6 has an unmet dep:
> Depends: qt1g (>= 1.42-1)
> Package ssltelnet version 0.11.2-1 has an unmet dep:
> Depends: libssl08
>
> Jason
>
> ---------------------------------------------------------------
>
> Subject: RE: list archiving software
> Date: Wed, 06 Jan 1999 14:46:51 -0800 (PST)
> From: Darren Benham <gecko@benham.net>
> To: Wichert Akkerman <wichert@cs.leidenuniv.nl>
> CC: Debian Developers <debian-devel@lists.debian.org>
>
> Basicly, the list archives are maintained by Guy. You'd have to check with him
> or it'd be hijacking...
>
> On 06-Jan-99 Wichert Akkerman wrote:
> >
> > I've been getting email from people complaining that they cannot read
> > anything I send the the mailinglist in the archives, since they cannot
> > handle the PGP/MIME encoding that mutt uses.
> >
> > Is there anyone who can fix this? If nobody steps forward I'll give it a
> > shot myself, but I have no idea what kind of archiving software we use.
> >
> > Also, if we fix the archiving scripts, does that mean that we can use
> > that for older mail as well?
> >
>
> --
> =========================================================================
> * http://benham.net/index.html <>< *
> * -------------------- * -----BEGIN GEEK CODE BLOCK----- ---------------*
> * Darren Benham * Version: 3.1 *
> * <gecko@benham.net> * GCS d+(-) s:+ a29 C++$ UL++>++++ P+++$ L++>++++*
> * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- *
> * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b++++ DI+++ D++ *
> * <gecko@debian.org> * G++>G+++ e h+ r* y+ *
> * -------------------- * ------END GEEK CODE BLOCK------ ---------------*
> =========================================================================
>
> ---------------------------------------------------------------
>
> Part 1.14.1.2 Type: application/pgp-signature
>
> ---------------------------------------------------------------
>
> Subject: Re: Overall Unmet dependencies
> Date: Thu, 7 Jan 1999 00:45:09 +0100 (CET)
> From: Vincent Renardias <vincent@ldsol.com>
> To: Jason Gunthorpe <jgg@ualberta.ca>
> CC: Debian Developers <debian-devel@lists.debian.org>,
> debian-testing@lists.debian.org
>
> On Wed, 6 Jan 1999, Jason Gunthorpe wrote:
>
> > I was bored so here is an interesting report for you all. The packages
> > listed here CANNOT be installed but are included in slink, they should
> > probably be removed or fixed ASAP.
>
> > Package libfltk-dev version 0.99-1.1 has an unmet dep:
> > Depends: libstdc++2.8-dev (>= 2.90.26-1)
> > Package pppload version 1.0-6 has an unmet dep:
> > Depends: qt1g (>= 1.42-1)
>
> I've uploaded fixed versions of those 2 yesterday.
> You can fetch them from Incoming/
>
> Cordialement,
>
> --
> - Vincent RENARDIAS vincent@{{ldsol,pipo}.com,{debian,openhardware}.org} -
> - Debian/GNU Linux: http://www.openhardware.org Logiciels du soleil: -
> - http://www.fr.debian.org Open Hardware: http://www.ldsol.com -
> ---------------------------------------------------------------------------
> -"Microsoft est ŕ l'informatique ce que le grumeau est ŕ la crépe..." -
>
> ---------------------------------------------------------------
>
> Subject: Re: Overall Unmet dependencies
> Date: Wed, 6 Jan 1999 14:43:34 -0800
> From: Joey Hess <joey@kitenet.net>
> To: Jason Gunthorpe <jgg@ualberta.ca>
> CC: Debian Developers <debian-devel@lists.debian.org>,
> debian-testing@lists.debian.org
>
> Jason Gunthorpe wrote:
> > Package doom-musserver version 1.0-7 has an unmet dep:
> > Depends: doom (>= 1.10-11)
>
> Should be removed. I think there's a ftp.debian.org bug on this.
>
> --
> see shy jo
>
> ---------------------------------------------------------------
>
> Subject: Re: Adopting dpkg-ftp
> Date: Wed, 6 Jan 1999 22:43:37 +0100 (CET)
> From: Yann Dirson <ydirson@mygale.org>
> To: Jason Gunthorpe <jgg@ualberta.ca>
> CC: Debian Developers <debian-devel@lists.debian.org>
>
> Jason Gunthorpe writes:
> >
> > On Tue, 5 Jan 1999, Yann Dirson wrote:
> >
> > > IIRC, when I checked it mainly missed error recovery for
> > > low-reliability PPP lines - dpkg-ftp offers to try to go on dowloading
> > > a Packages file or a .deb when an error occurs.
> >
> > This might make a future cut with APT.. right now it aborts the troubled
> > file and goes on to the next one, if you run it again it will resume the
> > troubled file transparently.
>
> I'm not sure if we're talking about the same thing. I'm talking about
> an FTP timeout occuring while a .deb or a Packages.gz has been partly
> dowloaded. In this case, dpkg-ftp << 1.4.9.1 just stop, and I don't
> recall that the versions of apt I have tried did much better.
>
> > > Maybe it also misses some of the other features I had added to
> > > dpkg-ftp for hamm - see changelog for details.
> >
> > I didn't see anything.. The v3 version has support for firewall
> > configuration which should cover the last set of features.
>
> OK. Here are the main features I'd like to see in apt-ftp before
> switching to it. I would find it very nice if all of them were
> already implemented.
>
> - timestamp check to select which Packages.gz to get
> - support for experimental-type dists (Packages.gz in ./ not in
> binary-${arch}/)
> - robustness wrt timeouts (re-parsing the DB's at start of the install
> method is slow enough on my 486/33 which has not yet been upgraded to K6/2)
> - minimization of the time when the PPP link has to be running (one of
> the worst points in dpkg-ftp 1.5.x BTW)
> - ability to differ the download of some packages selected for upgrade
>
> Here are accessory features I had added to dpkg-ftp because others
> need them:
>
> - emulation of MDTM (for timestamp checks) because of dummy firewalls
> rejecting it
>
> You may also be interested in the bug reports I filed against dpkg-ftp
> 1.5.x for removal of some of these features that Klee probably did not
> thought were really features.
>
> Regards,
> --
> Yann Dirson | Why make M$-Bill richer & richer ?
> <ydirson@multimania.com> | Support Debian GNU/Linux:
> debian-email: <dirson@debian.org> | Cheaper, more Powerful, more Stable !
> http://www.multimania.com/ydirson/ | Check <http://www.debian.org/>
>
> ---------------------------------------------------------------
>
> Subject: Re: Adopting dpkg-ftp
> Date: Wed, 6 Jan 1999 16:00:49 -0700 (MST)
> From: Jason Gunthorpe <jgg@ualberta.ca>
> To: Yann Dirson <ydirson@mygale.org>
> CC: Debian Developers <debian-devel@lists.debian.org>
>
> On Wed, 6 Jan 1999, Yann Dirson wrote:
>
> > Jason Gunthorpe writes:
> > >
> > > On Tue, 5 Jan 1999, Yann Dirson wrote:
> > >
> > > > IIRC, when I checked it mainly missed error recovery for
> > > > low-reliability PPP lines - dpkg-ftp offers to try to go on dowloading
> > > > a Packages file or a .deb when an error occurs.
> > >
> > > This might make a future cut with APT.. right now it aborts the troubled
> > > file and goes on to the next one, if you run it again it will resume the
> > > troubled file transparently.
> >
> > I'm not sure if we're talking about the same thing. I'm talking about
> > an FTP timeout occuring while a .deb or a Packages.gz has been partly
> > dowloaded. In this case, dpkg-ftp << 1.4.9.1 just stop, and I don't
> > recall that the versions of apt I have tried did much better.
>
> That is what I was talking about as well. APT does not stop (never did)
> but it gives up on that one file, it still tries all other files that have
> been queued.
>
> > OK. Here are the main features I'd like to see in apt-ftp before
> > switching to it. I would find it very nice if all of them were
> > already implemented.
> >
> > - timestamp check to select which Packages.gz to get
> > - support for experimental-type dists (Packages.gz in ./ not in
> > binary-${arch}/)
>
> These have been supported from day 1.
>
> > - robustness wrt timeouts (re-parsing the DB's at start of the install
> > method is slow enough on my 486/33 which has not yet been upgraded to K6/2)
>
> Reparsing the db and preparing to download files is quick in APT [My
> 486-33 takes 7-15s with the old ver, it is below 8 with the new one], even
> faster in APTv3 and all transfers are carefully controlled with a timeout
> mechanism.
>
> A single failed file (due to a timeout or otherwise) does not effect all
> other files that will be fetched and APTv3 supports an unlimited number of
> fallback sources that are tried should the main source fail for any
> reason.
>
> > - minimization of the time when the PPP link has to be running (one of
> > the worst points in dpkg-ftp 1.5.x BTW)
>
> pon;apt-get update;apt-get -dy upgrade;poff; apt-get upgrade
>
> > - ability to differ the download of some packages selected for upgrade
>
> It can't do this, but you can download single packages by hand with
> 'apt-get install foo'
>
> > - emulation of MDTM (for timestamp checks) because of dummy firewalls
> > rejecting it
>
> I don't think the current APT ftp method does this, in truth most people
> using firewalls will probably want to use http urls which don't have that
> pesky problem.
>
> Jason
>
> ---------------------------------------------------------------
>
> Subject: Re: list archiving software
> Date: Wed, 06 Jan 1999 14:45:48 -0800 (PST)
> From: Darren Benham <gecko@benham.net>
> To: Martin Schulze <joey@tapiola.infodrom.north.de>
> CC: Debian Developers <debian-devel@lists.debian.org>
>
> On 06-Jan-99 Martin Schulze wrote:
> > Do you care to define "fix"? The scripts are fine. They extract
> > attachements into extra files (iirc) which then can be checked
> > against the given signature.
> The list archiving that we use for the WWW site show's emails signed in
> multipart as essentially empty. The text and signature and such are lost.
>
> --
> =========================================================================
> * http://benham.net/index.html <>< *
> * -------------------- * -----BEGIN GEEK CODE BLOCK----- ---------------*
> * Darren Benham * Version: 3.1 *
> * <gecko@benham.net> * GCS d+(-) s:+ a29 C++$ UL++>++++ P+++$ L++>++++*
> * KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- *
> * Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b++++ DI+++ D++ *
> * <gecko@debian.org> * G++>G+++ e h+ r* y+ *
> * -------------------- * ------END GEEK CODE BLOCK------ ---------------*
> =========================================================================
>
> ---------------------------------------------------------------
>
> Part 1.19.1.2 Type: application/pgp-signature
>
> ---------------------------------------------------------------
>
> Subject: Re: Overall Unmet dependencies
> Date: Wed, 6 Jan 1999 15:16:26 -0800
> From: Joseph Carter <knghtbrd@debian.org>
> To: Jason Gunthorpe <jgg@ualberta.ca>
> CC: Debian Developers <debian-devel@lists.debian.org>,
> debian-testing@lists.debian.org
>
> On Wed, Jan 06, 1999 at 03:39:52PM -0700, Jason Gunthorpe wrote:
>
> > Package ktop version 0.9.7-3 has an unmet dep:
> > Depends: kdebase
> > Depends: kdelibs0g-dev
> > Depends: kdelibs0g (>= 2:980710)
>
> Should be removed from slink. Leave it in potato though.
>
> > Package libfltk-dev version 0.99-1.1 has an unmet dep:
> > Depends: libstdc++2.8-dev (>= 2.90.26-1)
>
> Wasn't this recompiled I thought?
>
> > Package qtscape version 5.0.19980408-1 has an unmet dep:
> > Depends: qt1-snapshot (>= 1.39.19980414-1)
>
> Should be removed or recompiled. Either way would work.
>
> > Package pppload version 1.0-6 has an unmet dep:
> > Depends: qt1g (>= 1.42-1)
>
> That qt is present in potato, why is this package in slink?
>
> --
> "Uhh, it's not what you think.." "Oh? Yes, how disappointing."
> -- Forever Knight
Reply to: