[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#644900: marked as done (apt from testing cannot read archives created with apt-utils from stable)



Your message dated Fri, 14 Oct 2011 13:43:52 +0200
with message-id <CAAZ6_fBOMXfwH1zVQfNbs3oqDM9i_qRtEeHvTTntwgDaH7fkCA@mail.gmail.com>
and subject line Re: Bug#644900: apt from testing cannot read archives created with apt-utils from stable
has caused the Debian Bug report #644900,
regarding apt from testing cannot read archives created with apt-utils from stable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
644900: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644900
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 0.8.10.3+squeeze1
Severity: normal

Hello,

I am creating apt archive using the following script (which uses pool split by
release).

It works flawlessly with stable apt but with testing I get:
W: Failed to fetch copy:/var/lib/apt/lists/partial/127.0.0.1_debs_dists_squeeze_live_binary-amd64_Packages Hash Sum mismatch

The file is still compressed in this location. Decompressing and
checksumming yields the checksum present in the Release file as stable
apt correctly determines.

There is
/var/lib/apt/lists/partial/127.0.0.1_debs_dists_squeeze_live_binary-amd64_Packages.decomp.FAILED
which is a copy of the compressed list above.

I suspect that apt does not decompress the file before use. When I
modified the script to do checksumming after compression I got error
about invalid field before package header.



#!/bin/sh -ex

archs="i386 amd64"
suite="stable"
codenames="lenny squeeze"
comp="live"

for codename in $codenames ; do

rm -f dists/$suite
ln -sf $codename dists/$suite

find $codename -name \*.deb -exec dpkg-name '{}' ';'

for a in $archs ; do

mkdir -p  dists/$codename/$comp/binary-$a
dpkg-scanpackages -a $a -m $codename /dev/null >
dists/$codename/$comp/binary-$a/Packages
rm -f dists/$codename/$comp/binary-$a/Packages.*

done

#-o APT::FTPArchive::Release::Date= \
#-o APT::FTPArchive::Release::Version=None \

apt-ftparchive \
-o APT::FTPArchive::Release::Origin=hramrach \
-o APT::FTPArchive::Release::Suite=$suite \
-o APT::FTPArchive::Release::Codename=$codename \
-o APT::FTPArchive::Release::Architectures="$a" \
-o APT::FTPArchive::Release::Components="$comp" \
-o APT::FTPArchive::Release::Description="Some packages patched for
testing/debugging stuff in d-l" \
-o APT::FTPArchive::Release::Label="hramrach's Debian Live patch
repository" \
release dists/$codename >dists/$codename/Release

gpg -b dists/$codename/Release
mv dists/$codename/Release.{sig,gpg}


for a in $archs ; do
gzip -f -9 dists/$codename/$comp/binary-$a/Packages
done

done


-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: wheezy/sid
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'testing'), (410, 'unstable'), (200, 'experimental'), (111, 'oldstable'), (107, 'natty-updates'), (107, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apt depends on:
ii  debian-archive-keyring  2010.08.28      
ii  gnupg                   1.4.10-4        
ii  libc6                   2.13-21         
ii  libgcc1                 1:4.6.1-13      
ii  libstdc++6              4.6.1-13        
ii  zlib1g                  1:1.2.3.4.dfsg-3

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc     0.8.10.3+squeeze1 
pn  aptitude    0.6.3-3.2+squeeze1
pn  bzip2       1.0.5-6           
pn  dpkg-dev    1.16.1            
pn  lzma        4.43-14           
pn  python-apt  <none>            

-- no debconf information



--- End Message ---
--- Begin Message ---
Hi Michal Suchanek,

looks for me like your script is buggy:
You are creating a Release file and signature for it and only after that
you compress the Packages files, which means you have now Packages.gz files
which are not in the Release file, but you have Packages files in your
Release file which doesn't exist. The error message i get with your script is
therefore different: stat error because the file doesn't exist.

Previous APT versions tried unconditional to load certain compressed Packages
files, but as this is pretty dumb and costly if multiple compressions are
supported it looks now at the Release file to know which compressions are
available: In your Release file only the not compressed file is "available"…

So move your for-loop for compression creation before signature creation and
use a line like this instead to create the compressed files:
cat dists/$codename/$comp/binary-$a/Packages | gzip -9 -f >
dists/$codename/$comp/binary-$a/Packages.gz
This way the uncompressed Packages file is preserved as it is needed by
APT to create a good Release file. You can remove the uncompressed files
after creating the release file if you like.

Alternatively you should have a look at 'apt-ftparchive generate' to replace
most of your script… Attached are two more comments on your script.

I am therefore closing this bug now, but feel free to reopen it if
i misunderstood something.


Best regards

David Kalnischkies


> #!/bin/sh -ex

This script is a bash script and not sh thanks to this line:
> mv dists/$codename/Release.{sig,gpg}


> -o APT::FTPArchive::Release::Description="Some packages patched for
> testing/debugging stuff in d-l" \
> -o APT::FTPArchive::Release::Label="hramrach's Debian Live patch
> repository" \

The rest of the mail includes longer lines, so i am not sure if these are
auto-wrapped lines or if your script really has this lines wrapped:
It will not hav the desired values in that case as these fields are one-line
fields… (it doesn't fail through, but some parsers of these files might fail).


--- End Message ---

Reply to: