Yum-presto (deltarpms) ready for testing.

[Ahmed Kamal]

Manually downloading the drpm, and using applydeltarpm manually might show
some useful information as to 'why' reconstruction is failing

On 3/26/07, Jonathan Dieter <jdieter at gmail.com> wrote:
>
> On Mon, 2007-03-26 at 19:17 +0200, Leszek Matok wrote:
> > This one is strange:
> >
> >
> =============================================================================
> >  Package                 Arch
> Version          Repository        Size
> >
> =============================================================================
> > Updating:
> >  bittorrent *            noarch     4.4.0-5.fc6      extras
> 59 k
> >  bittorrent-gui *        noarch     4.4.0-5.fc6      extras
> 15 k
> >  lucidlife *             i386       0.9.1-2.fc6      extras
> 90 k
> >
> > Transaction Summary
> >
> =============================================================================
> > Install      0 Package(s)
> > Update       3 Package(s)
> > Remove       0 Package(s)
> >
> > Total download size: 164 k
> > Is this ok [y/N]: y
> > Downloading Packages:
> > (1/3): bittorrent-gui-4.4 100% |=========================|  15
> kB    00:00
> > (2/3): lucidlife-0.9.1_0. 100% |=========================|  90
> kB    00:03
> > (3/3): bittorrent-4.4.0_4 100% |=========================|  59
> kB    00:02
> > Rebuilding full packages from deltas
> > Traceback (most recent call last):
> >   File "/usr/bin/yum", line 29, in ?
> >     yummain.main(sys.argv[1:])
> >   File "/usr/share/yum-cli/yummain.py", line 172, in main
> >     base.doTransaction()
> >   File "/usr/share/yum-cli/cli.py", line 419, in doTransaction
> >     problems = self.downloadPkgs(downloadpkgs)
> >   File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 706, in
> downloadPkgs
> >     self.plugins.run('postdownload', pkglist=pkglist, errors=errors)
> >   File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in
> run
> >     func(conduitcls(self, self.base, conf, **kwargs))
> >   File "/usr/lib/yum-plugins/presto.py", line 174, in postdownload_hook
> >     raise PluginYumExit("Error rebuilding at least one deltarpm.  Please
> run report this error
> to\nhttps://hosted.fedoraproject.org/projects/presto/newticket.  To bypass
> this problem, run yum \nwith the --disablepresto option")
> > NameError: global name 'PluginYumExit' is not defined
> >
> > Notice the part "lucidlife-0.9.1_0.". Next time (1 minute later, no
> > repository metadata was updated) it was different:
> > (1/1): lucidlife-0.9.1-2. 100% |=========================| 723
> kB    00:24
> > And the update went okay. It looks to me like a deltarpm repository
> > breakage combined with some strange logic in Presto that made it
> > download a file with another name that it wanted.
> >
> > Oh, and there's no /var/log/presto.log.
> >
> > Lam
> Okay, first an explanation:
> Presto works by checking to see if there is a deltarpm update available
> for each package.  When there is a deltarpm available, it then checks
> what's called the "deltarpm sequence" against your system to see if the
> deltarpm will apply cleanly.  If the deltarpm will apply cleanly, it
> then changes certain package information, in this case to
> lucidlife-0.9.1_0.9.1-2.fc6_1.fc6.i386.drpm.  Yum then proceeds to
> download the drpm (thinking it's the rpm).  After yum downloads all the
> packages, presto kicks in again and reassembles the rpm from the drpm,
> and reverts the package information back to the original.  And, finally,
> at the end, it writes out statistics to /var/log/presto.log.
>
> So, what has happened here is that the lucidlife drpm looked like it
> would apply cleanly the first time around, but, after being downloaded
> didn't apply cleanly.  A bug in the code gave you that ugly error rather
> than the "nice" error message it was supposed to...I'll fix it in 0.2.8,
> which should be out in a half-hour or so.  The second time your ran it,
> it realized there was a problem and downloaded the full rpm.
>
> I would really love to know if you've done anything with lucidlife,
> changed any files before upgrading to the latest version?  It would help
> me work out why we hit this error in the first place.
>
> Jonathan
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070326/55a99c94/attachment.htm>