Am Mon, Mar 11, 2024 at 12:12:45PM + schrieb Colin Watson:
> "rmadison clustalw" shows:
Shame on me I always forget about rmadison which explains things
perfectly.
> So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it
> has to be kept in the pool; files are only expired fr
On Mon, Mar 11, 2024 at 01:06:49PM +0100, Andreas Tille wrote:
> Yes, I've filed this and this was perfectly intended (even if I forgot
> that the bug is done meanwhile which I should have checked before asking
> here - sorry about this). It was just that all signs that this package
> exists are r
Am Mon, Mar 11, 2024 at 11:41:42AM + schrieb Colin Watson:
> Search for "clustalw" in https://ftp-master.debian.org/removals.txt:
>
> [Date: Mon, 26 Feb 2024 18:19:39 -] [ftpmaster: Thorsten Alteholz]
> Removed the following packages from unstable:
>
> clustalw | 2.1+lgpl-7 | ar
On Mon, Mar 11, 2024 at 12:06:58PM +0100, Andreas Tille wrote:
> Debci seems to be fine in testing clustalw on all architectures[3] and
> according to build logs[4] all should be fine. Unfortunately
>
>wget -q -O -
> http://ftp.debian.org/debian/dists/sid/main/binary-i
eated using
sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian
Debci seems to be fine in testing clustalw on all architectures[3] and
according to build logs[4] all should be fine. Unfortunately
wget -q -O -
http://ftp.debian.org/debian/dists/sid/main/binary
Package: general
Version: 2817
Severity: important
I rsynced binary-i386-2.iso from cdimage.debian.org and the ISO image
itself passes the MD5SUMS check; this proves that the problem I discovered
is something everybody will encounter when they get their CDs from CD
distributors who burn
Hi,
I'll be burning some copies of the 2.0-beta images today.
If anyone in the UK wants a copy, mail me. (I expect I'll do them for a fiver
each, depending upon the numbers involved).
If anyone that's going to the UKUUG Event in Manchester this weekend wants a
copy, mail me, and I'll bring on
Hi,
It struck me as important that the autoup stuff go on the CDROM image, so I've
added it to the root directory in a directory called autoup.
This contains the 8MB tarball, as well as the script and readme etc.
so we shouldn't have problems with version skew between autoup.sh and
the main arch
"Douglas" == Douglas Bates <[EMAIL PROTECTED]> writes:
Douglas> To follow up on my own post - this was reported as bug
Douglas> #21025. In the bug report the date on the file was Apr 2.
Douglas> Now it is Apr 24 but it is still zero length.
In case I haven't mentioned it enough, the Packages fi
Douglas Bates <[EMAIL PROTECTED]> writes:
> I notice that the Packages file for slink/main/binary-i386 on master
> is empty ...
To follow up on my own post - this was reported as bug #21025. In the
bug report the date on the file was Apr 2. Now it is Apr 24 but it is
still zero len
Sorry if this has already been discussed but I have been away for a
week and off the list. I notice that the Packages file for
slink/main/binary-i386 is empty whereas binary-alpha, binary-powerpc,
and binary-sparc all look as I would expect them to. Is this a subtle
hint that I should switch
Package: ftp.debian.org
lftp ftp.debian.org:/pub/debian/dists/slink/main/binary-i386> ls -l Packages*
-rw-r--r--1 102481608 0 Apr 2 13:56 Packages
-rw-r--r--1 102481608 20 Apr 2 14:46 Packages.gz
lftp ftp.debian.org:/pub/debian/dists/slink/main/binary-i
Could "binary-i386" be added as a symbolic link until the files are actually
moved. I'd like the version of dftp I'm about to release to handle an
architecture setting.
Brian
13 matches
Mail list logo
